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 15:56:41 GMT
--- Christoph Wilhelms <>
> Hello Simeon (again)!
> After taking an even closer look at what you build I
have to say:
> I think your code is very complex and I think unqiue
in java... I've seen
> such constructs in C++...

Can you offer specifics? I think it is probably more
an issue of understanding the design approach,
primarily the mechanism by which events are translated
into commands. This is the one area where a cusory
look may initially be confusing. Events encapsulate
the communication of a request, a response, or a
notification (e.g. a change of state). For example, if
the user wants to invoke a build, a build request is
submitted to the bus (manifested as an ActionEvent).
Certain listeners on the bus have the opportunity to
veto that request, but if it isn't, then the request
is converted into a Command which is the encapsulation
of performing a task.

At this early stage of the application's development
this is obviously overkill, but in my past development
efforts where I haven't implemented such encapsulation
I have had to go back and do it later, once the
application reached a certain critical complexity
level. I wanted to avoid rework at the framework

> I understand what you do with the commands and
specially the events and
> busses! What I do not unterstand is: why are you
doing it this way for
> there
> are really easier ways to implement
Listener-funktionality! Simply build
> Listeners!

When I have taken a pure Listener/Event Generator
approach in the past I have ended up with a tangled
web of interdependencies, especially with complex data
models. And you never seem to have access to the
particular piece of data you want as you add a new
feature. You then have to go back and modify
constructors, etc. to pass down the information you
want. With the combindation of the AppContext class
and the EventBus class, you have access to all
application resources and information without having
to register with lots of different event generators.

> Further questions are:
> Why do you pass the AppContext throug the whole
application? Single
> componentes have nothing to do with it! We can pose
global things like
> resources etc. into a Singleton-pattern class!

Again, a lessons learned thing. A Singleton is a
euphomism for a global variable, which should be used
sparingly (there are some appropriate cases). In
Antidote such a case hasn't arisen yet. The purpose of
the AppContext class is the encapsulate all
application state and resources. What this immediately
gives you is the ability to instantiate to GUI windows
with two separate projects in one JVM. If singletons
were used then you could only host one GUI/project in
one JVM. Further more, you could even have two GUI
screens sharing the same AppContext class, and in that
case they would offer a "collaborative" type
experience. I think you'll find in the long term that
the AppContext is a good thing.

> Why do you instantiate your gui via reflection? It's
so easy to bouild
> singel componentes (beans) an compose a gui! Really

So that you can have different configuration files for
different application setups. It also makes it easy
for people to add or remove whatever modules they want
to use, e.g. install IDE plugins that not everyone
else wants to use (this capability isn't totally in
place yet). And not all of us use GUI buiders ;-)

> Ups... I should have read your Antidote - design
document! I overread it
> in
> your mail! I'm going to read it now and - possibly -
some of my questions
> are outdated then!

I hope that it answers some of your questions. Let me
know if there are areas of the document that are
unclear or need filling out.


Mustard Seed Software

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

View raw message