ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simeon Fitch <>
Subject Re: Antidote design proposal/discussion
Date Sun, 19 Nov 2000 22:24:05 GMT

Sorry for the delay in replying. Hopefully my discussion below should help
get you where you want to be relative to contributing to Antidote.

--- Christoph Wilhelms <> wrote:
> I'd propose consequently using the JavaBeans-design architecture for the
> Antidote GUI-Beans. I have concrete
> Idease of an implementation as "independent"-Beans whithout giving up the
> bus-architecture and keeping the low
> coupling! The beans-architecture will make it easier for others to take
> part
> in the antidote-develoement, for we
> could easyly plug the beans together (even with reflection!)

First, I think I need to provide a little background on the use of
reflection in the GUI, as I don't think it is clear, or its benefits easily
recognizable (and someone else thought it was a little odd). If you look at
the file at the top you will notice several settings
that relate to the "AntEditor" classes that are installed at startup. The
locations top, bottom, left, and right are defined, which correspond to
configurable areas in the main Antidote frame. You can put zero or more
AntEditor instances in each of these areas, where multiple instances are
distinguished through the use of a tabbed pane.

The reason that reflection is used instead of hard coding main GUI screen
(or saving the serialized bean state from a GUI builder) is so that someone
can develop their own custom, in-house (or otherwise) "AntEditor", then
download Antidote and install their editor via a simple modification of the
Antidote configuration file (rather than editing and recompiling Antidote).
Basically it's just a framework for implementing plug-ins. It's not
perfect, or complete, but it's satisfactory for right now.

This is a feature that is certainly not necessary at this stage of
development, but because I had implemented this capability (actually a much
more extensive version) on a past project with great success, I went ahead
and implemented it as I was growing the application framework.

Now back to the JavaBean issue.

Correct me if I'm wrong, but I think the only thing inhibiting the use of
the Antidote "AntEditor" modules as drag-n-drop JavaBeans is the fact that
I require a constructor of form <init>(AppContext). Conor aptly pointed out
that there is no *objective* reason that the following approach can't be
used instead for instantiating the "AntEditor" classes:

    Class editorType = Class.forName(classNames[i]);

    AntEditor editor = editorType.newInstance();
    editors[i] = editor

In other words, provide a default ctor, and install the required data
references via an init(AppContext) method. If I changed the code to use
this approach would it not meet the basic requirements for a JavaBean for
GUI builder use? Obviously a Customizer and BeanInfo would  be needed for a
nice setup, but I think this is the only thing inhibiting you from using
the components in your evironment.

I can certainly make the above change, but I'm still not sure I see the
benefit to the development of the Antidote GUI. I can can certainly see
benefit to reusing the components in other applications, and I guess I want
to know if /that/ is your main reason for wanting the Antidote components

If it is an issue of redesigning the GUI, rather than adding to it, I think
I'd like to first see proposals for a different approach, and then have
those agreed changes implemented by hand rather than through the use of a
builder tool. I personally think the high-level layout of the GUI is
sufficient in the near term, and the module abstraction (as described
above) is featurefull enough for you or anyone else to go off and start
building editors or other views unimpeeded as long as they extend the
AntEditor class.

If you are looking for specific modules to work on, here are some

1) The class receives BuildEvent objects as generated by the
running build. The console allows one to set a threshold level for setting
the "verboseness". It would be visually appealing if messages of different
logging levels had different appearances in the Console window. Therefore
we need a) the support for managing a set of AttributeSet objects that
would be used by the Console class whenever it does an insertText() on the
JTextPane it uses, and b) an editor and associated persistence support for
allowing the user to change the default properties of the above
AttributeSet set.

2) Right now the class is the only place where the user gets
any feedback on the current status of the build. I'm not sure exactly what
the right UI model for this is, but if I'm watching a long build I want to
know what target it is in, what task is being executed, how much more is
left to go. If it fails, I want to know what stage in the chain of targets
the failure occurred in (outside of looking through the console). I keep
thinking of a horizontal timeline each target that will be executed is
represented, with the current target being executed highlighted in some
way. Then maybe inside that target the current task is displayed. To be
able to do this you will probably have to get one of the Ant developers to
open up the API that does the topological sort, as it is currently declared
private. You can grab this information upon receiving the AntBuildEvent
with the type tagged as BuildEventType.BUILD_STARTED. From this you can get
the original BuildEvent, which contains the Project object in it that has
the topological sort algorithm in it.

3) When you select a node in the project navigator, the PropertyEditor
screen uses the JavaBeans Introspector class to retrieve not only the
BeanInfo for the class, but also the class's customizer. The acs package
contains defined BeanInfo classes for the project, property, target, and
task nodes. Right now, all of the task nodes are handled by the same
BeanInfo class, which only exposes generic editing capabilities for the
node (setting the attributes via a name/value editor). The file in the taskdef package in the Ant source is loaded
in order to know which elements are tasks, and are then assigned a generic
DOM object to sit behind it. What is needed for each task is a real DOM
class (see the ACSTargetElement for an example), and then a corresponding
BeanInfo class for it (see ACSTargetElementBeanInfo). Right now I recommend
relying on the DynamicCustomizer as the assigned Customizer for the
BeanInfo, and then later after the basic functionality is in place we can
go back and implement more specialized Customizers for the Beans where it
would be appropriate.

4) Right now you can only edit an existing build.xml. Furthermore, there is
currently no way to add or remove nodes from the build file definition. A
set of actions and associated commands is needed for inserting new and
removing nodes/elements. These actions would just fire an add/remove
ActionEvent, and the command handling them would refer to the
ProjectProxy.getSelectionModel() to determine what is selected, and then
perform the appropriate operation on that selected item.

5) At some point a wizzard will be needed to help put together a basic
build.xml file for standard build operations. This is where lots of help
from the mailing list should be leveraged, as defining the appropriate
contents of a template build file is key. The wizzard should step the user
through the process of defining some basic properties for the build file
(name, included jar files, locations, etc.) with lots of suitable defaults.
A wizzard framework should be implemented that allows other developers to
easily insert nodes in the wizzard process using a standard text editor
(i.e. no GUI builder required).

I hope you find at least one of these tasks interesting (personally I find
them all interesting). Let me know which of these you are interested in so
I don't go off and duplicate effort.



Mustard Seed Software

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

View raw message