I present to you…

Polite Focus!

It’s a simple idea – use document.activeElement to determine if an existing field has focus. If not, give your field focus. Otherwise, leave the focus where it is, where someone else (user or previous programmer) decided it should be.

That’s it.

Go forth and use wisely

I’ve created a repo on GitHub so you kids can branch and comment as much as you like.

Go clone the plugin on GitHub. Now.

One drawback to using a library that does magic is that if you’re not careful you can miss some important details. In this case I’m talking about injecting your views into the DOM. Blindly following the create view/render into element pattern as described in the documentation is usually fine. However, if you are using a view to render a list of children the $(this.el).append(view.render().el) quickly becomes costly.

For my needs I wanted to add an arbitrarily-long list of elements to an ordered list. Instead of blindly looping over models, creating views and shoving them into the list one at a time I decided to add all rendered views into a document fragment in memory and then append that fragment on to my list. Clean code for rendering, only one DOM adjustment for speed.

Example Code!

var containerView = Backbone.View.extend({
//... snip
	render: function() {
		var template = _.template($('#regular_ol_template').html()),
			self = this;

		$(self.el).html(template(self.model.toJSON()));

		self.list = $('.list', self.el);

		var frag = document.createDocumentFragment();
		_.each(self.model.things.models, function(thing) {
			frag.appendChild(self.createThing.call(this, question).render().el);
		});
		self.list.append(frag);

		return self;
	},

	createThing: function(thing) {
		return new ThingView({model:thing});
	}
//... snip
});

But why make a separate function?

What you’re not seeing is another method named addThing which uses createThing and does more work – to my model, spinning up other views, etcetera. It’s also good not to bind the creation of elements solely into your render method. You want to be able to add more things to your list without fully re-rendering it. That way, should someone else decide to use my model or view in the app, elements in the list can be adjusted without the performance overhead of creating the whole list again.

Result

There you have it! You have now rendered your Backbone.js views into memory and appended them to the DOM in one fell swoop. Instead of abusing the DOM in your loop cycle you’ve speedily created them in memory. Isn’t that much kinder to the DOM? The answer is yes, yes it is.

What do you think? How would you change this? Comments!

For many years I’ve either been working on boring enterprise integration stuff or amazing tech that I’m not allowed to yet share with the world. That makes for a fairly silent blog and twitter feed. Unless, of course, you want me to talk about the sandwich I had for lunch and omigod how annoying are drivers in [your local commute path]?

But things have changed! I’ve been working on some awesome code, projects and platforms lately and I have some neat code that I think should be shared with the programming community.

Thankfully I’m seeing some progress here from management towards openness and embracing the community. That means not only do I get to talk about some of the crazy stuff I’ve done here but also start open sourcing our code!

Bam. It’s going to be cool. But hold on to your knickers cause enterprises are slow moving beasts. Patience, kids…

One of the things we do is emulate the UIMenuController with our own more powerful view controller. And one of the neat things about a UIMenuController is that you get a slick, subtle drop shadow wherever it is placed. Being the guy I am I spent some time to analyze the drop shadow in Photoshop and do my best to emulate it. Here’s what I came up with. Have a better solution? Tell me in the comments!

- (void) viewDidLoad
{
	[super viewDidLoad];

	self.view.layer.shadowColor = [[UIColor blackColor] CGColor];
	self.view.layer.shadowOffset = CGSizeMake(0, 2.0f);
	self.view.layer.shadowOpacity = .55f;
	self.view.layer.shadowRadius = 2.0f;
	self.view.layer.shouldRasterize = YES;
}

See what I’m saying? Fade out what isn’t important, lighten all matches, put some special pizazz on the current item. As an added bonus each time you switch the current item it “pops” a bit to help pull your eye to where the next item is. Pretty slick.

I set out not to duplicate the styles but to get a feel for CSS3 animation and transitions. With that in mind the animation tweens and colors aren’t exact but they’ll work for the project I have in mind. If you have improvements go ahead and share them in the comments.

[Ninja edit] I forgot to mention that in order for CSS transformations to be hardware accelerated by devices that do so you have to include the “translate3d” property. If you don’t need to translate, use the meaningless zeroed out setting like I did below.

[Ninja edit 2} Also, I didn’t bother putting in all the different vendor prefixes. If you’re interested in this code your Google-fu will be strong enough to look up the different vendor settings and adjust accordingly.

@-webkit-keyframes pulseFocusedOverlay {
	0%, 100% {
		-webkit-transform: scale(1) translate3d(0px, 0px, 0px);;
	}
	15% {
		-webkit-transform: scale(1.35) translate3d(0px, 0px, 0px);;
	}
}

.searchMatch {
	display: inline-block;
	padding: 0 4px;
	margin: 0 -3px;
	-webkit-box-shadow: 0 1px 5px #333;
	box-shadow: 0 1px 5px #333;
	color: #222;
	background-image: -webkit-gradient(linear, left bottom, left top, color-stop(.5, rgb(222, 222, 222)), color-stop(1, rgb(255, 255, 255)));
}

.searchMatch_selected {
	display: inline-block;
	padding: 0 4px;
	border-radius: 5px;
	border: 1px solid #EFDB13;
	margin: -1px -4px;
	-webkit-box-shadow: 0 1px 3px #333;
	box-shadow: 0 1px 5px #333;
	color: #000;
	-webkit-animation: pulseFocusedOverlay 185ms ease-in-out 0;
	background-image: -webkit-gradient(linear, left bottom,left top,color-stop(.5, rgb(238, 207, 0)),color-stop(1, rgb(242, 237, 19)));
}

With defensive programming in mind there sometimes exists a need to peek into the CSS that is loaded into the browser. Say an application your writing depends on user-based styles that are dynamically loaded in. It’d be nice to inject those styles into the document CSS and know you’re not overwriting anything. Perhaps your code is meant to take an existing style and modify it.

To this end I present a work-in-progress of my first jQuery plugin, CSSelection.

Code: View CSSelection on GitHub

Download jquery.CSSelection.js

CSSelection start by accepting a jQuery selector. With that selector you can read the current styles applied to that selector, add new styles, create such a selector if one does not exist or even remove the current selector from the stylesheet. I tried to keep the interface predictable to jQuery users at the expense of a bit of extra code. Passing no arguments retrieves the current rules, if any, of the selector. Passing the string “remove” does as expected to first found matching selector in the style sheets. Finally passing an object literal with rules will either add them to the stylesheet or modify the matching selector.

While this code is used in production I’ll still call it beta as bugs are cropping up in IE9 and are sure to arrive in future revs of Safari and Firefox. Enjoy!

Usage examples

How to create a rule for HTML elements:

$('p').CSSelection({rules: {'font-size': '120%', 'color': 'red', 'background-color': '#fff'}});

Modifying existing CSS rule/add new rule:

$('.important').CSSelection({rules: {'text-decoration': 'underline overline', 'background': 'yellow'}});

Delete a CSS rule:

$('.annoyingDecoration').CSSeleciton('remove');

Get attributes for existing rule:

var attrs = $('.wickedAwesomeClass').CSSelection();

And DOM ranges are terrible.

I don’t mean they are a terrible idea. I mean they’re terrible to work with. Of course there is no single, standard API to work with. Of course Internet Explorer adds another level of challenge. And of course you’re going to at some point have to know how these things work if you expect to be a JavaScript ninja.

There are many reasons to deal with ranges. Some lame services will hijack your selection and inject in their own tags. If you’ve ever needed to hack around a WYSWYG editor then ranges will be on the docket. Or say you’re leading a team that allows users to select text on a page and do things like highlight it, make a note attached to it or even place a bookmark at that point in the page. That’d be my job.

The default range object seems good enough for a lot of tasks. Where it starts to show its weakness is interacting with the DOM outside of just the range.

You want to take what a user has selected and wrap it in a decorative <span>? That should be easy, right? What happens if that selection starts in the middle of an <li>, moves down a few paragraphs, enters a <div> and ends a few levels deeper in the node tree? Well, you can’t just wrap that in a single element.

The browsers all try to be helpful. Really, they do. If your range starts in the middle of an <em> tag but ends outside of it the range you get back from the browser will automatically split the tag properly if you wrap it. That’s nice. But if you remove that wrapper now you have a split tag that equates to more child nodes in memory than in code. That makes for bad assumptions later.

During my research into and development of this project I’ve found a stunning lack of comprehensive information (much less example code) for DOM ranges. Obviously PPK is the place to start but his level of detail is light and — at best — beginner. I’ve worked with some guys at Google who are on the Closure Library team and are ridiculously smart. Even they didn’t plan for the basic needs I have. Or it could be I’m doing it wrong.

In any case, I’ll be working on a series of entries to this blog that will go through what I’ve learned, show some code, talk about common pitfalls, propose some best practices and hopefully shine some light on the dark corner that is DOM ranges.

Using a Mac is great. You can pry mine from my cold, dead hands. However, there are times I need to run things in a Windows VM. It’s easiest to do as much work as possible in VM but there’s the unavoidable need to connect remote machines to the guest server.

In my specific case I am part of a team developing a C# app so that means Visual Studio 2008 and its built-in development server, Cassini. Microsoft added this lovely hard-coded trick to Cassini so that it listens only to requests from the loopback, localhost. This is supposedly to prevent developers from shipping apps with Cassini built in. I don’t care about the reason. I care that I can’t connect to my development VM on my Mac or any other remote machine. There is a fairly simple solution to that, though.

My setup

• OS X 10.6.3
• VMware Fusion 3.0.2
  • Windows 7 Professional
  • Visual Studio 2008
  • VPN’d connection to the office

Yes, it’s wonky to VPN in my VM but I can’t VPN in my Mac and that’s a whole other story.

What you’ll need

• Fiddler

That’s it.

The Concept

Fiddler is a debugging proxy but it also has the ability to be a reverse proxy. We’re going to use that feature to take requests to the guest VM on Fiddler’s port of 8888 and automatically reroute them to Cassini’s port.

The Execution

First thing’s first: my particular setup is probably unique and the tedious steps I’m about to list will likely never be needed by the average developer. However, if I need them that tells me someone else does as well so this is bound to help some lucky Googler.

1. Make sure your VM’s network connection is running in Bridged mode
2. Start your Cassini server by going to Visual Studio in your guest VM and pressing ctrl+F5
3. Fire up Fiddler and open Tools->Options
4. In the Connections tab make sure “Allow remote computers to connect” is checked and hit OK to close the options window
5. Press ctrl+r to open the rules (defaults to opening it in notepad.exe)
6. Search for the OnBeforeRequest function and add the following condition:
   

   if (oSession.host.toLowerCase() == "192.168.1.108:8888") oSession.host = "localhost:5867";

   Just modify the 192.168.1.108 IP to be your VM’s IP and change 5867 to be Cassini’s port

7. Fire up cmd.exe and renew your IP by doing an ipconfig/release followed by ipconfig/renew

You’re done!

Testing your work

Now that Fiddler is set up to route requests to Cassini you can go to any machine on your local network, type in your VM’s IP followed by Fiddler’s port and Fiddler will accept your request, route it to Cassini and return back results. In case you need to copy and paste something the path in my browser is simply

http://192.168.1.108:8888

Ways to improve this

There’s an additional rule that can be added to Fiddler. In the OnBeforeResponse add the condition “oSession.utilReplaceInResponse("localhost:5867","192.168.1.108:8888");“. That does what it sounds like. You may have noted the magic numbers in the Fiddler rules. These will suck to maintain. You can right-click your web solution, go to properties, click the Web tab and assign a specific port. If you go to your Windows network settings and force in an IP you’ll never have to edit the rules file again. However, these are hack solutions around a weak implementation.

A potentially better route would be to ditch Cassini altogether and use UltiDev, a free .NET server. I may still. Should get around these headaches fairly well.

The best option would be to run IIS in your VM. For an as-yet-undiagnosed reason my web solution will not allow me to run it through IIS. I hope you, casual reader, have more luck.

Closing

There have to be more devs out there running a Windows VM in their Mac, needing to test their web apps in OS X, on their iPod Touch/iPhone/iPad, Blackberry, yada yada. Yes, this could all be solved by using the dev or QA server but those aren’t updated automatically and I can’t be bothered to make a build every time I want to tweak some JavaScript. I’m marking this down as an exercise in learning about VM networking types, reverse proxy functionality and the power of releasing and renewing your DHCP license.

While able to run in 64-bit, I was running Apache in 32-bit mode under my Leopard install. This is because the ODBC drivers I was running from Actual Technologies only supported 32-bit Apache. In Leopard land that was fine. Now that I’m in Snow Leopard and everything else is in 64-bit I thought my ODBC drivers ought be as well.

My problem is that I had the 32-bit Actual Technologies drivers, compiled in the FreeTDS drivers for my MSSQL support when compiling PHP and then installed a 64-bit beta build from Actual Technologies. Somewhere between the Snow Leopard upgrade and all these other installs things have gone a bit wonky. Best bet is to clean out all ODBC drivers and start anew.

Small hiccup: Actual Technologies does not provide an uninstaller. Well, not that you’d be able to find. I emailed their support and received a link to a script bundled up in a dmg. By request I’m not going to post a link to the script or the script itself and I think that’s fair. Looking at the script it is no more than a series of rm -rf commands that blindly erase whole directories. Even existing iODBC data and settings you may have from other products or drivers.

I’m going to run the uninstaller, recompile FreeTDS, rebuild PHP and see where that gets me. Hopefully not towards a fresh Snow Leopard install.

When Tommy finally gave jQuery a try and discovered there was no native DOM manipulation tools he decided to roll his own plug-in he calls FluentDom. The code is clean and quality, as I’d expect from him, but the interface drives me bonkers.

I’m a fan of configuration over convention, a concept which, when combined with my MooTools history, has lead me to favor using object literals as configuration “objects”. When I use MooTools to create a new element the only arguments are the element type and an object literal with any configuration options. This is where Tommy’s code style differs. In FluentDom you set a specific attribute with specific methods with calls able to be chained together. This isn’t to say that FluentDom couldn’t be used with a configuration object, it’s just not as clean an implementation as I prefer.

In a message to him I said this:

The benefit to setting attributes via an object literal is that I can use one set of preset attribute values and pass that around. Quite handy if you’re doing something like iterating and creating a list of similar elements but particular ones might have subtle differences. Also easier to maintain and extend. Given your code it’d be a trivial modification to do this during a create call.

Which do readers prefer, specific, chainable method calls or ambiguous configuration object?