ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simeon Fitch <>
Subject Re: AW: Antidote...
Date Wed, 15 Nov 2000 16:31:45 GMT

--- Christoph Wilhelms <>
> Hello Simeon!
> Yes, I am continuing my monologue :-)!
> I've just read your design document and the
> requirement doc.
> I do now understand why you are using
> Bus-Technology, but I 
> have to admit, that its not good, that every Event
> is passed
> through this Bus. In my opinion it only shlould be
> used for
> Ant-BuildEvents and Messages provides by the
> Ant-Model and
> even other more special events. GUI-Events are to
> special.

But why are GUI events special? And Event is an Event
in my mind. What if more than one component wants to
respond to an action, but the action generator, or the
default handler of the action don't know it? I don't
want to impose that kind of limitation or coupling on
the application if I don't have to.

Because each BusMember must provide a BusFilter, they
never receive events they aren't interested in.
Therefore, such generality doen't impose undue
requirements on the application components.

> There is no need that a click on a menuitem is
> passed throu
> the whole application - even as command. If we have
> our own
> "ProjectOpenedEvent" to let the multiple views know,
> that
> they have to update theirselvs, it should be posted
> throu 
> the Bus. Even better would be, when the model itself
> throws 
> events like: "I habe been changed!"
> (PropertyChangeEvents). 
> The view knows the model and each view could be a
> listener 
> to it's specific model... what do you think?

The posting of ActionEvent objects through the bus is
an experiment I'd like to continue with. Because most
of the components ignore ActionEvents anyway, I don't
think it is all that big of a deal to continue this
route. If some design reason arises that makes doing
such a bad thing, then it can be removed.

> I can live with the bus-system, but I don't agree in
> the way
> you instantiate the UI. I think UI-components should
> be Beans,
> wich can be assebled/composed to a bigger UI!
> Perhaps you can
> explain why you did it with reflection...

That's a fair criticism. But the components
(AntEditors) aren't really custom widgets, which are
more useful as beans in a wire-it-up type of IDE. I
also don't want to be forced to expose a default
constructor, and then have some sort of 'init()'
method that sets everything up after all the
"setXXX()" methods have been called.

What I think you are probably frustrated with is the
fact that I'm not a GUI builder user (I like to hand
tool things), and you are, and some of the design
decisions that I've made, for better or worse, don't
accomidate the GUI builder approach to assembling
applications. Again, that's a fair criticism, but also
somewhat of a religious one (like Emacs vs. VI), as
I've heard arguments on both sides of the aisle that
claim that one approach is better that the other. At
least once a year I try out a few of the latest
builders and still find that I end up with more
maintainable and architecturally robust code if I go
the hand-tooled route. But maybe I'm just an old


Mustard Seed Software

Do You Yahoo!?
Yahoo! Calendar - Get organized for the holidays!

View raw message