Re: AW: Antidote...

[Simeon Fitch <me...@yahoo.com>]

--- Christoph Wilhelms <Ch...@tui.de>
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:simeon@fitch.net

__________________________________________________
Do You Yahoo!?
Yahoo! Calendar - Get organized for the holidays!
http://calendar.yahoo.com/

Re: AW: Antidote...

[Peter Donald <do...@apache.org>]

At 07:55  15/11/00 -0800, you wrote:
>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.

Have a look at the Avalon mailing list archives because I went into a lot
of detail regarding readability and I think I may have given a few pointers
to current state of research on it if you are interested ;)

Cheers,

Pete

*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device.      |
*------------------------------------------------------*