At 20:20 2002-08-09 -0500, Tom wrote: >[...]Three of them are already available on CPAN, so I'm currently >focusing on >implementing the HTML::DOM module. > >Any comments?
Yes: I'm happy someone's actually doing this! For ages, this JavaScript thing has been one of those projects where people keep saying "Boy, it'd be nice if SOMEONE (and not me!) went and did that". As to the DOM specifically: I think the best way to think of the DOM spec is to do the following: 1) Imagine that it was written by five or six neurotic Swissmen who knew only Ada, which they used to code in in the 70s, then had a severe nervous breakdown, had to go live in a room with soft walls for a few decades, then in 1998 were released and taught Java, then encouraged to write the DOM spec as part of their "release program". Try to spot the parts of the spec that they wrote as they were changing medications! 2) Some of the hardest parts of the DOM to implement are probably the least useful. I remember something particularly horrid about the linearization of a tree being an object that actually changes if the tree changes. Simply appalling. 3) The DOM claims to be language-neutral, but remember: ADA, Java, neurotic Swissmen, etc.. So it's really just Java-neutral. For example, if I want a list of all the attributes and values of an element, you'd think it'd be something like $element->attributes, and it'd return (key1, value1, key2, value2) etc. But no, it's getAttributes, and returns an iterator over a list of namednodemap objects, where each map has a getName and getValue method. This is deeply maddening. So I suggest looking for ways to make things simpler for (non-JavaScript) users of the HTML DOM. Like you could add a $element->attributes method as I described (since the DOM spec is just a minimum of what to do, not all you're allowed to do); or you could make $element->getAttributes behave according to spec in scalar context, but return (key1, value1, key2, value2) in list context. In fact, I think this could be a generally useful approach: for each method, asking "can I make this do something simpler in list context"? Maybe look at HTML::Element and Tree::DAG_Node for inspiration. I wouldn't hold up either as The One Right Way to do trees, but they're both certainly not afflicted by the same manias as the DOM. I'd love to change my HTML::DOMbo module to build HTML::DOM trees instead of XML::DOM trees, since I've heard that the latter class isn't well supported. -- Sean M. Burke http://www.spinn.net/~sburke/
