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