RE: [xml-dev] better (?) than DOM

["Nathan Young -X \(natyoung - Artizen at Cisco\)" <natyoung@cisco.com>]

I think your points are very good.  I realized looking back at it that the whole "DOM is or might be broken" premise was a bit of a troll.

If you measure success based on how much something is used then DOM is kicking but.  The fact that there is a new layer of APIs coalescing atop the DOM API could be taken as further proof of that success.

Of the examples I sent, the shortcuts for creating nodes was the strangest and at the same time it was the least specific to interface coding in the browser in that many of the contexts in which DOM programming is used require creating and adding nodes.

I'll repost with a little explanation because I'm curious if anyone has seen something like this.  Absent XML4J it's not completely crazy to create violent shortcuts for creating nodes programmatically.  Although it is chained method calls, it comes remarkably close to looking like a markup language:

jQuery('#myDiv').append(
    jQuery.DIV({'class':'big'},
        jQuery.SPAN({id:'one','class':'ps'},
            'Hello Joe', jQuery.I({},'!')
        )
    )
);

If you started with:

<root>
   <div id="myDiv"></div>
</root>

and ran the code shown above you'd end up with:

<root>
   <div id="myDiv"><div class="big"><span id="one" class="ps">Hello Joe<i>!</i></span></div></div>
</root>

---->Nathan


.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:._.:||:.

Nathan Young
Cisco.com->Interface Development
A: ncy1717
E: natyoung@cisco.com  

> -----Original Message-----
> From: Manos Batsis [mailto:manos_lists@geekologue.com] 
> Sent: Thursday, February 22, 2007 4:24 AM
> To: Nathan Young -X (natyoung - Artizen at Cisco)
> Subject: Re: [xml-dev] better (?) than DOM
> 
> Quoting "Nathan Young -X (natyoung - Artizen at Cisco)"
> <natyoung@cisco.com>:
> > [...] The
> > perennial topic is "DOM programming is 
> broken/clunky/doesn't fit task
> > X well and should be replaced/enhanced/etc"
> 
> Whether DOM is broken or not is largely irrelevant IMHO. Browsers have
> built their codebases on lots of legacy stuff that makes the situation
> more complex, for example their distinction between XML and HTML (i.e.
> tagsoup) nodes and hence, the incompatibility between those.
> Interoperability is probably the greatest obstacle.
> 
> 
> [...]
> > I'm not aware of any crosstalk between JS library creators 
> and anyone
> > who may be working on formal enhancements to DOM.
> 
> Making good DOM extensions is not trivial; different code styles and
> backgrounds makes it hard to come up with generic requirements. Some
> people are client-side purists while others demand better integration
> with their server-side logic. In other news, binding data state to UI
> elements or widgets is something XForms tried to do with few 
> followers.
> 
> 
> > I think over the next
> > year or so these libraries are going to consolidate and some good
> > ideas will float to the top.
> 
> Perhaps they will, but the competitive mentality right now 
> leaves little
> room for co-op. Mailinglists where created for the purpose 
> that ended up
> as generic ajax talk.
> 
> 
> > This is a long way from pure DOM programming and it goes deep in
> > javascript only territory.  Parts of it though are pure shortcut
> > across multiple DOM calls.
> 
> I think thats natural. DOM had to address different types of languages
> (as in strongly versus loosly typed) so different implementations of 
> the Façades/utility methods are appropriate in different languages.
> 
> My point is, (i think :-) that DOM more or less did what it had to do
> and the situation you describe concerns not the API but the 
> client-side
> scripting community, the browser vendors and the interaction 
> between the
> different (sub)parties in those.
> 
> Kindest regards,
> 
> Manos
>