--- Christoph Wilhelms <[EMAIL PROTECTED]> wrote: > 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 fogey... sim ===== Mustard Seed Software mailto:[EMAIL PROTECTED] __________________________________________________ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/
