ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simeon Fitch <meta...@yahoo.com>
Subject Re: Proposed Revolution: AntEater (a proposal for Ant Core 2.0)
Date Tue, 14 Nov 2000 02:48:15 GMT
--- James Duncan Davidson <duncan@x180.com> 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:simeon@fitch.net

__________________________________________________
Do You Yahoo!?
Yahoo! Calendar - Get organized for the holidays!
http://calendar.yahoo.com/

Mime
View raw message