Friday, June 22nd, 2007

Magic DOM

Category: JavaScript, Library

Amir Salihefendic has taken the idea from MochiKit and developed a standard alone 2k DOM library called Magic DOM.

Instead of writing:

javascript

  1. var dl = document.createElement('dl');
  2. dl.className = 'my_dl';
  3. var dt_equ = document.createElement('dt');
  4. dt_equ.innerHTML = 'Equipments';
  5. dt_equ.className = 'my_dt';
  6. dl.appendChild(dt_equ);

you would do:

javascript

  1. var dl = DL({'class': 'my_dl'},
  2. var dt_equ = DT({'class': 'my_dt'}, 'Equipments'));

Download MagicDOM for more info.

Posted by Dion Almaer at 6:24 am
17 Comments

++---
2.3 rating from 22 votes

17 Comments »

Comments feed TrackBack URI

I wrote DomBuilder a while a go and this is almost identical except that it doesn’t include the cross browser attribute support (which renders this version pretty unusable to be honest). If you want this functionality I’d really recommend using DomBuilder:

http://svn.danwebb.net/external/DomBuilder/trunk/dombuilder.js

Comment by Dan Webb — June 22, 2007

The example seems to be missing something. Line 7 of the “original” adds ‘dt_equ’ as a child of ‘dl’. I would be very surprised if line 2 of the example also accomplishes this.

Comment by Jakob Kruse — June 22, 2007

Actually it does.
dt_equ is being passed as an argument to the DL() function.

Comment by Eduardo — June 22, 2007

You can check out the HTMl/XML for JavaScript (http://www.ivy.fr/js/xml) that enables you to do the same things, but you can also generate markups for RSS, RDF, etc using a simple Python script.

Comment by Sébastien Pierre — June 22, 2007

Looks exactly like MochiKit.DOM, and just about all the other libraries… what does it offer that makes it more attractive than the existing libraries?

Comment by Theo — June 22, 2007

@Theo: It’s stand-alone and light-weight. Not everyone would include an entire library for one functionality.

Comment by Andy — June 22, 2007

only thing i don’t like is having those function names left in the wild of the global namespace.
It’s good to see people taking Mochikit’s codebase and working from it.

Comment by gonchuki — June 22, 2007

@Jakob

I think you’re right. This seems to be a syntax error:


var dl = DL({'class': 'my_dl'},
var dt_equ = DT({'class': 'my_dt'}, 'Equipments'));


var dt_equ = DT({'class': 'my_dt'}, 'Equipments');
var dl = DL({'class': 'my_dl'}, dt_equ);

The first example posted by Ajaxian will have an error.

It’s a good example that shows how taking too many shortcuts can make the code less explicit, and lead to bugs, which are not easy to pinpoint. Jakob found it.

DOM delegate.

Adds more symbols to the global namespace by creating a series of functions which delegate to the DOM.

The benefit is that it is shorter to use than the DOM.

The drawbacks would be: decreased performance due to unnecessary delegate, less explicit, and harder to debug, adds more symbols to the global namespace, which could possibly create a problem.

Comment by Garrett — June 22, 2007

There are sure a lot of these. Dan’s DomBuilder is great. There’s also my old DOM creator for jQuery and Prototype (which actually doesn’t depend on either library) from January 2006.

A comment in the Magic DOM post suggests an alternative syntax, which happens to be about the same as Olsow’s version that was posted as a comment to my DOM creator article a year ago. If you like that syntax, a more fully developed version is Ken Stanley’s FlyDOM for jQuery, which is now used at digg.com.

These days I don’t even use my own DOM creator much – instead I use good old innerHTML. Much faster!

Comment by Michael Geary — June 22, 2007

I tend to use Dan’s DomBuilder, except when I have to build a lot of nodes. Used with MooTools (especially .adopt()), it makes some rather clear code. If something doesn’t run fast enough, I optimize afterwards by switching to .innerHTML changes.

Comment by Eric — June 22, 2007

last i checked FlyDOM was 8x as long as my version and didnt support adding inline event handlers for the elements – once you start doing that with nested functions, lexical scoping and closures you can eliminate the use of selectors (and their inherent selection time) and fragile parent/subling/child traversals…

but the general concept is great. its too bad using an object literal for each DOM literal is more verbose than using an array..

Comment by mozbeast — June 22, 2007

I still do this with simple innerHTML, to add handlers I grab elements by getElementsByClassName, $ or $$. Example:

var d = $(document.createElement(‘div’));
d.update(‘Equipments’);
return d.firstChild;

For me it’s the most consequent and natural way to create Element( tree)s. Why use third party libs in this case?

Comment by Andi — June 22, 2007

Because innerHTML is unpredictable, non-standard and doesn’t return references.

Comment by Hans Schmucker — June 23, 2007

During the development of the first releases of PassPack, I adopted Easy DOM Creation by Michael Geary to quickly manage the DOM elements. But, with the beta4 version of PassPack I needed to overcome Michael’s library’s limits (due to the compatibility with Prototype). So I developed jQuick. It is at http://jquick.sullof.com

Comment by Francesco — June 23, 2007

@ Hans:
– Then a page loaded and build of xhtml will inpredictable, too. Because it’s parsed at runtime just like innerHTML.
– InnerHTML is a nice function that works in all browsers.
– Thats why I use the firstChild thing ;)

Comment by Andi — June 23, 2007

innerHTML may lead to a broken DOM if injected code is erroneous.
using DOM building functions ensures DOM’s sanity and allows for extra functionality such as adding behaviours or setting properties to nodes.

Comment by gonchuki — June 25, 2007

Anyone tested this with the input element?
Just found that IE does not write the name attribute when created in runtime

Comment by ta — June 27, 2007

Leave a comment

You must be logged in to post a comment.