[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: DOM's javascript roots (was Re: Have JDOM / XOM
On Mar 31, 2006, at 20:15, Tatu Saloranta wrote: > This used to be one of main selling points for DOM > (raison d'etre, even) -- no matter the language, you > know the API. I thought it was an urban legend (portal > theory for coders), but I guess it isn't. ;-) It is an urban legend. How you use the DOM varies not only from language to language but also from implementation to implementation. It's not so much that they don't interoperate, but rather most have this or that shortcut that you'll use -- except perhaps in the only case in which interoperability across DOM implementations matter, which is to say in the browser. >> I think it's worth pointing out at this stage that >> JavaScript >> programmers don't appear to seek or design >> alternatives to DOM at all. > > Part of the reason of which probably is that, since > DOM was created FOR Javascript (standardized what > Netscape had built for its needs) No, I don't think that's true. If the DOM had been created for Javascript it would be a *lot* less horrible than all the hoops it had to jump through to support utterly braindead languages like Java. Also, if it had been about standardising what Netscape had built it would be a lot more horrible than it is. I believe much of the horror was due to having to support Java, and having to get Netscape and MS on the same page, which probably involved making some wrong decisions just to get consensus. It's true though that in many languages the DOM is a lot less painful than it is in Java. If you have a language in which you can bind anything that's actually a list in the DOM to the language's native notion of arrays, and if you have a language that supports objects that know their own type so that you don't have to cast them five times every other line of code you find that using the DOM isn't all that painful. Throw in XPath, which the DOM WG started work on too late IMHO, and you've got something quite decent. I can't count the number of Perl programs I have that just rely on the DOM and XPath — they tend to look an awful lot like a bunch of XQuery FLOWR expressions, except you don't have to learn a new language and you have access to all the stuff you normally get from your language. I'm sure experiences in the rest of the OO and dynamic realm (Ruby, Python, etc.) are similar. The reason alternatives to the DOM have not been all that successful for Java is because Java is all about cargo-culting and pain. Cargo- culting as in you throw IO exceptions when you write to memory, because it looks like what the other guys are doing (I don't even count those anymore), so if other folks are using the DOM you use the same, none of that crazy new stuff can possibly be any good. Pain as in if you've resigned yourself to need seven lines of code to open a text file for writing, honestly it's not the DOM that's going to scare you. Add to that the pain that adding an extra JAR brings, with all the deployment headaches, you certainly won't be much tempted to throw in XOM or JDOM. -- Robin Berjon Senior Research Scientist Expway, http://expway.com/
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|