~ryanlowe/blog: Practical Use for DOM?

Practical Use for DOM?

Andrew says about a project he's working on:

The whole system is based around the notion of selective nodes that can have only certain types of children....

The first thing I thought of when I read that was XML, DOM and a DTD. Did you look into using a DOM tree for the representation?

If you use a DTD a good validating parser won't let you add XML nodes that violate the DTD. Then you can just use the DOM (model) to make the UI's the tree view (view) and then all you need is a controller (to complete the MVC pattern) -- in SWT the controller is the TreeContentProvider. The rules for the children types are in the DTD, separate from the implementations of the GUI and business logic.

A group I worked with at Corel did the same thing. Ironically, they had us studying XML for a month solid beforehand. So when I saw the project with XML fresh in my mind I said "couldn't XML make this hierarchy?". They said "well we could but it's too complicated" ... classic NIH. After two months of battling and much distillation of requirements they finally agreed with me when our intermediate "tree" format ended up looking exactly like a DOM tree. I scrapped it and replaced it with DOM. My co-op term ended two weeks later ... and that team is no more -- let go this winter. Ah well, lesson learned.

Posted at April 25, 2003 at 10:03 PM EST
Last updated April 25, 2003 at 10:03 PM EST

Comments

The data format is XML - and using JDOM we convert it to our own tree representation for several reasons... i will use 'I' so that i don't put words in the other developers mouths

1) I was not interested in a DTT or a Schema... we are slowly migrating our stuff to talk with UMI (the xml for uml i believe) used by ArgoUML to *draw* usecases.... so if anything we may adapt their memory object structure

2) I wanted domain specific methods without all the fluff and error handling and jdom (see my posts about exceptions) ...

3) I wanted something easily testable... it is nice that when you separate code and information about what the code should do (like using reflection) - but that can make the system more complex and less testable...

4) I do not know enough about DOM to know the difference between using it externally (aka as a data format and parsing it into memory) and internally (aka adding new sheeat into memory) or even about the various implemenations of DOM and SAX ... to know if it could handle the few simple things that i wanted like
+ only allowing addition of nodes in order... so that if i'm already at c's in my list then i can only add things that are c's and on (so, no more a's or b's added to the end of the list)
+ limiting the number of a certain type of node (so only 1 x or only 2 y's for example)
+ extending the functionality of a 'node' (element, whatever) without adding bugs to the existing system (perhaps because some methods were not declared final - but should have been)
+ making sure that a node can only have 1 parent (so if another parent grabs it - then the original relationship is gone)

Good point "couldn't XML make this hierarchy" - i am still just a little skeptical about using it as an internal structure... once i get on a paid project to investigate this sheeat - hopefully i'll start using dom a little more internally too :)

» Posted by: andrew at April 29, 2003 01:22 AM

I don't blame you for being skeptical, XML et al is a lot of stuff.

» Posted by: ryan at April 29, 2003 08:30 PM