--- Christoph Wilhelms <[EMAIL PROTECTED]> wrote: > Hi Simeon! Christoph, I'm going to be forwarding your emails to the dev group as I think it is important that these discussions about Antidote and proposed approaches you offer. There are many people interested in Antidote and where it is headed, and also would like to get some background on the design decisions I've made.
> > First of all: There was no problem for me to compile/run antidote for I > am > usin IBM VisualAge for Java 3.5 - just imported Antidote into my Ant > Project - and it worked :-)))! No Problem with that! Great! >I took a look at > your > UI-code and, well, I think I could optimize it, and makit a little bit > more > "readable...". The primary goal at this stage is to get the architecture design and frameworks solid and robust. Optimization is not an issue at this time (though I'm surprised you found anything inefficient other than some of the event delivery code, which I've documented as such). Getting a solid design in place will facilitate optimization later, and such a task should only be undertaken if 1) an inefficiency is detected via user experience or resource loading, and 2) the inefficiency is located using some sort of profiling tool. To paraphrase the computer scientist Dr. Bill Wulf: "More sins in computer science have been commited in the name of optimization than any other activity, and often to the detriment of the the goal they undertake". High on my goals list is modularity and minimal coupling, and I'm willing to impose some reasonable inefficiences to maintain these goals. That being said, it is always an issue of balance that one must navigate. As for the "readable" issue, I'm open to suggestions because I have tried to fully document my code and use good naming practices. Readability is a big hot button with me, so I'm interested in what your isues are. >I'll send you a codesnipped later on, that you can see how > we > develop and structure GUI-code. I know that there are many ways to structure GUI code, and everyone has their pet approach, including me. Without getting into a long discussion on past experiences, I do have to say I have some very specific resons for the way I have structured the code, some of which are documented in the design doc, and some which I need to do a better job of communicating. These design decisions are in many cases the culmination of lessons learned in past GUI development efforts, and areas where I have regretted not putting in provisions for future growth. > We > depend > a little on the cod VAJ generates - but just a little! > I'm sorry, but that won't work here. I am rabidly against using code generated by any vendor's IDE; they force you to conform to their design constructs, the code is often ugly and hard to maintain, and it imposes an additional learning curve on those who want to contribute to the code base. Some would argue that it takes a lot longer to hand code GUIs then using a builder tool, but my experience has been the opposite, and even if it weren't, I still believe you end up with a more robust tool in the end provided that you abide by the architecture and design constructs throughout the effort. > I have various Ideas to improve the UI with - for example I have the idea > of > a universal LogPane (architecture like JOptionPane) wich can display Ant > Messages - later on probably Log4J Messages, too... > What do you propose it would do over what the Console class does already? > What do you think of sharing the work by cutting antidote horizontal in > the > middle - that means: I could do the UI Plugging the Componentesd together > and doing the UI-desing (for this is my real profession - and passion); > ofcourse we should discuss the design "ofline"; and your task would be > the > really "demanding" things, like DOM-Based three Models, how to make the > modified XML-file persistent again, dealing with the ant API and so > on....? > > Wouldn't that be nice :-)? > I would prefer that delegation of tasks be more on a module basis. I have worked hard to allow this thorough the definition of the "AntEditor" (admittedly a bad name) abstract base class. If you implement this interface, and then add your editor to the appropriate place in the antidote.properties file it will be available in the GUI. The point being, that if you have a great idea for a module (I'd like to see one that graphically tracks the status of a build), implement it as a module and plug it in! Modules and send and receive all events, and have access to all application resources through the AppContext, so it has as much power as any other component. So I recommend that you propose a component you want to work on and go for it. Even though some of the infrastructure is in flux, accomidating changes shouldn't be all that big of a deal. Let's keep the dialog going. Thanks for your input, sim ===== Mustard Seed Software mailto:[EMAIL PROTECTED] __________________________________________________ Do You Yahoo!? Yahoo! Calendar - Get organized for the holidays! http://calendar.yahoo.com/
