--- James Duncan Davidson <[EMAIL PROTECTED]> wrote: > I'm open to discussion, of course. So I guess I need > to understand why you > want these elements to implement the Element > interface... Right now I don't > see the need for the internal model to be a DOM impl > where everything is > abstract -- just that the model match up with the > external XML > representation on "factual" basis.
What I'm hoping for is that the Ant data nodes just implement the Element interface so that they could be realized in a full, type inspecific data structure if you wanted it to... >Data round > tripping rather than > byte-to-byte round tripping. And I'm going to try to argue that you can have it both ways :-). It is all dependent on how you construct your data structure, not necessarily by what types it implements. >I can infer that you > would like the DOM for > editing purposes, Primarily at this point. Simple navigation code is another one. >however DOM elements are abstract > and I would think that > as a GUI (and that tasks, etc) would prefer to work > strictly with strongly > typed objects. Yes and no. Your argument for strongly typed objects is a good one and one that I'm for. That's why even though, say, the Project class would implement the Element interface, it would still have a set of Ant specific methods that would provide the Ant specific traversal semantics. As far as Ant "The Build Tool" code goes, it would probably rely exclusively on such methods. However, in the GUI, generality can be win a lot of functionality for free. To illustrate this let me talk about what the current GUI does (at least when you run it under Java 1.2, but that's another story): I have my own mirror of the Ant data model which implements the DOM semantics. To display it in a navigator type tree all I have to do is implement a TreeModel class that knows how to traverse the tree structure for the JTree widget. The JTree doesn't care if it is a Project, Task or a Foo, it just wants to know how to display it (which is delegated to a separate class), and whether or not it has children to show. With a DOM structure this TreeModel class is insanely simple *because* it deals with general types. Second example: editing a "node". This is where you would think that strong typing would win, but it really doesn't if you use the JavaBeans architecture. The way the GUI works now is that you click on a node in the aforementioned navigator, which sends a selection event to a thingy called the PropertyEditor. The PropertyEditor doesn't care what type of thing you want to edit, cause all it does is get the object's BeanInfo class which tells it how to edit the object. How does it know? At startup you register an editor for the *specific* type, and the JavaBeans framework takes care of the rest. To go even further, the current editor that I have in place is dynamically generated by requesting the object's JavaBean PropertyDescriptors and generates a property editor on the fly, just like your IDE would. All the type specific code is rolled up into a BeanInfo specialization. So to make a long story short, rapid GUI development thrives on using general types in as many places as possible (within reason), and defers type specific presentations and operations to a few select classes that do the appropriate interpreting for the rest of the application (think of them as views, not in the MVC sense but in the Database sense). > > Is your concern with keeping comments and such > inline with the tasks/targets > they represent? Yep. And the ability to traverse a homogeneous structure. > Yep. By all means send the wish list my way -- by > Friday as my net > connection to my laptop gets severed Monday AM. > The only other big one for me is the ability to register java.beans.PropertyChangeListener instances with the data nodes so that if say Project.addTarget() were called then a change event would be generated. Note that such code needn't affect the execution performance of Ant "The Build Tool" if implemented properly. Basically, if the Ant data model follows the JavaBeans specification (which is ridiculously simple if you're not familiar with it), and implements the org.w3c.dom.Element interface, then I'll be a happy camper. Thanks! sim ===== Mustard Seed Software mailto:[EMAIL PROTECTED] __________________________________________________ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/
