--- Peter Donald <[EMAIL PROTECTED]> wrote: > At 06:41 14/11/00 -0800, you wrote: > > Software Engineering 101 - Have the simplest > possible interface that can > represent what you need.
But Professor, what about leveraging existing standards and frameworks? ;-) > DOMs element is very > complex, slow and bloated. It > was designed with the idea of cross language support > etc and in reality was > a failure - see JDOM @ www.jdom.org who redid DOM in > a java way. > > Now do we need the functionality provided by Element > interface ? I would > say no to about 80% of it - and thus it is not > really a good idea to create > 80% new interface methods that will not be widely > used. The JDOM stuff looks very nice, and I think I understand where you are coming from with your argument. I admit that my proposal for extending org.w3c.dom.Element is only *one* option, and after thinking about what you said probably not the best one. I think I've so far been swayed by the idea of using the Element interface because there are other tools out there that know how to speak "w3c DOM", if you will. I love to be able to leverage other's work, but in our case the so called "bloatedness" of the w3c framework may be too much. Since you pointed out that I've forgotten what I was taught in Software Engineering 101, I should admit that I forgot my SE 102 lessons as well; in my arguments I made the mistake of focusing on implementation rather than requirements. So let me step back and list the requirements I hope to have met. 1) A navigatable tree structure that is faithful to the XML file structure. 2) A common base class (other than Object) that the tree nodes inherit from for those cases where generality can be represented and common behavior gathered (like an abstract write() method and generic getParent() and getChildren() methods). 3) The ability to reconstruct the XML input, including comments, by appropriate traversal of the tree. 4) (The most GUI specific, but also useful for scripting) The ability to register PropertyChangeListener instances with the nodes to be informed of property changes. > > Well have a look at JDOM (www.jdom.org) and Much nicer than w3c DOM! > Configuration interface in > Avalon project (java.apache.org/framework). Can you give me a package name? I briefly search through the CVSWeb and only ran into a configuration package with everything in the Attic. I'm very interested in learning more. > Configuration elements are a > 1-to-1 mapping with what Ant currently uses - JDOM > is a drastically > simplified DOM model that is performance sensitive > ;) I'm certainly interested in learning more from the lessons that Avalon has to offer. I'm sure duncan already has his ideas on how he wants to do things, but do you have some proposals you can make on how to meet the desires for a common data model? > > But they may - and then when other people read their > tasks it will be > difficult decipher (near impossible in some cases) > and it adds a lot of > extra bulk that is not needed IMHO. > Not to kill a dead horse, but if tree traversal semantics are tucked away in in a base class above Task.java, then those people extending Task.java can focus on the methods that it provides and requires for implementation. It's kinda like the thread support that's stuffed into the java.lang.Object class; you never think about the fact that it is there unless you are working with threads. Though I concede that there are many other options that use of the w3c interfaces for the data model, I think your case here about complexity is overstated. Thanks for the good dialog tho! sim ===== Mustard Seed Software mailto:[EMAIL PROTECTED] __________________________________________________ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/
