Crawl, Walk, Run

Any JavaScript developer who spends more than a blink of an eye working with the DOM has probably come despise the API. It’s not that there’s a dearth of features (welll….); I think it’s the verbosity that causes modern application development woes. For the one-off script that adds an onclick or modifies some text the DOM API is fine and dandy. Try scaling up to developing an application or, perhaps, a framework and things get annoying and messy right quick.

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?

Despite research that feels all-inclusive, reading other blogger’s posts and the collective groans on Marc’s message board (not to mention my own now-invalid feeling of accomplishment) I am still being bested by the infamous “child pid xxxxx exit signal Segmentation fault (11)” issue.

From what I can tell the segmentation fault occurs when I execute odbc_fetch_array. I cannot tell you what a joy it is to try and debug a script that dies when using a built-in function. PHP 5.3 how I wanted to love you. How I so very much despise you now.

If anybody out there in the tubes has any helpful, constructive ideas I sure would appreciate some feedback in the comments.

A coworker, Tommy, posed an interesting question to me the other day. How would one handle dynamically adding elements to a form, especially with regard to giving the user ability to remove those elements? We both admitted to implementing this a few times and he described to me his method of iterating through elements until the right node was found and then removing it.

As a habit I avoid DOM traversals whenever possible so I suggested an alternate solution. Instead of having a controller function look for some kind of unique ID or scan the DOM why not break down the control to the individual element and programmatically make the removing function a closure with a reference to each node. That way the code to remove an element is only ever concerned with its own instance. No crawling the DOM, no messy lookups, no muss no fuss.

If that didn’t make sense, perhaps this snippet will.

var addControls = function(element)
{
	var remove = document.createElement('input');
	remove.setAttribute('type', 'button');
	remove.setAttribute('value', '-');
	remove.onclick = function()
	{
		return function(self)
		{
			if(confirm('Are you sure?'))
				self.parentNode.removeChild(self);
		}(element);
	}
	
	element.appendChild(remove);
}

addControls(someNodeThatYouAlreadyFound);

Pretty simple. Questions? Let em rip in the comments.