jQuery Plugin: Objective C Learning Tool: Part 4

This is the final part of on ongoing series. Reading Part 1, Part 2, and
Part 3 will certainly help you understand what I’m going on about.

As promised, this is the wrap-up and the last you’ll ever hear about my little widget.

The first version of this was good enough, in the sense it did what I wanted it to do. However, it fell far short of being an unobtrusive, interoperable jQuery plugin. That took extra time, refinement, and research. This is the the crux of the software quality crisis that people having been worried about since there was software. Quality takes takes extra time, and there’s always someone willing to cut a corner that you’re not willing to cut.

Perfect is the enemy of done, but defining done is really really hard, and too often you don’t know you’ve made a mistake until it’s too late.

Gotcha

So, one of the original assumptions/requirements I set for myself at the start of this project was attaching the widget to a single element with an ID. Working specifically requires less thought than working generally and I just wanted to bang something out. Besides, when would I ever need more than one widget on the page? It didn’t help that I’ve spent the past 6 months working with Prototype, which is much more ID oriented. That’s where my mind was at.

But good enough, right? Well, it ended up biting me when I decided to start writing about the widget in a series of posts.

Normally I have the last few entries show up on my home page (landing page for you post-blogger kids). At that start of Part 2, I had to change how this worked. Two widgets on the same page didn’t work, because I had based all the IDs of new elements on the original ID of the element I attached to. This wouldn’t work when we attached by a generic selector (unless each matched element already had an ID, and all these hypothetical IDs were unique)

Final Steps

So, in order to fix this and implement the last step (iterating over the matched collection), I started off with the idea I’d need to generate unique IDs for each element. The egg-heads over at Stack Overflow put me off that idea.

Keep in mind: jQuery works with sets of elements, while
Prototype works with individual elements – you may be
better off adjusting your logic to fit this model.

With that in mind, I set off the re-factor my code, which is used on the two widgets below. The key missing piece was insertAfter

var oDisplay = $('<div></div>').insertAfter(this);
var oForm    = $(buildForm()).insertAfter(this);

The after() function/method will return a reference to the elements that were added-to. The insertAfter function will return a reference to the elements that were added. By assigning this reference to a variable I could later on attach event handlers

$(oForm).bind('click', function(e){        
...
});

and limit my future selectors (jQuery selectors, not Objective C) to a specific collection

var sSelector = '.'+src.className;
$(sSelector,oDisplay).css('background-color','#ff0');

So, with that in place, I think we’re once again at “good enough”, and next time I’ll know better. There’s certainly future refinements that could be made, but that’s always going to be the case.

There’s no such thing as a perfect piece of code, and there’s always something else that needs to get done.

//fake method to past in the boxes below...
-(void) this:(int)param is:(NSString)param2 an:(NSObject)param3 example:(NSArray)param4