Christoph and all interested,
If you don't mind I would like to tackle the custom editors. I believe I have
a solution that will create customized editors for each task found on the
classpath instead of just tables with the key/value look. An example would be
to examine all classes that inherit from Task or DataType, then, through
introspection, map each setXXX method to a property (which would give us
getXXX, setXXX, functionality without causing major work to be done on each
task/type).
Examination could be:
- load defaults.properties from ant.jar to get all the tasks we currently know
about.
- then start a thread to examine the classpath for any new tasks that may have
been added.
- if found update a master task list. (The only problem is that I am assuming
the name of the Task would be the name of the tag element).
Mapping could be done as follows:
- In a new customizer (DOMAttributesCustomizer) the setObject() method would
look like this:
/**
* Set the object to be edited.
*
* @param value The object to be edited.
*/
public void setObject(Object value) {
if(!(value instanceof DOMAttributes)) {
throw new IllegalArgumentException(
value.getClass() + " is not of type " + DOMAttributes.class);
}
_attributes = (DOMAttributes)value;
// Disable event generation.
_squelchChangeEvents = true;
// Iterate over each property, doing a lookup on the associated editor
// and setting the editor's value to the value of the property.
Iterator it = _prop2Editor.keySet().iterator();
while(it.hasNext()) {
PropertyDescriptor desc = (PropertyDescriptor) it.next();
PropertyEditor editor = (PropertyEditor) _prop2Editor.get(desc);
String key = desc.getName();
String attributeValue = _attributes.getProperty(key);
if(attributeValue == null) {
if(!_attributes.containsKey(key))
_attributes.put(key, "");
}
editor.setAsText(attributeValue);
}
// Enable event generation.
_squelchChangeEvents = false;
}
- Out of context this may need some explaining (if not please feel free to skip
past this section). The DOMAttributes extends the Properties class, but is the
class that DtdAttributePropertyEditor requires for a value in its
setValue(Object value). If the task has an associated class that it can
inspect we create the customized editor, otherwise we fall back on the familiar
table look.
- This would allow Tasks that don't have an associated getXXX for each setXXX
to be able to read the current value (to do this any other way we would need to
revamp each Task with a getXXX method for every setXXX, or at least those
methods that we want to read from).
My final suggestion:
Create a dtd for every task that could be stored in their own jar files. i.e.
for ant.jar the dtd would only specify those tasks that reside in the ant.jar
archive, the same with the optional.jar. Then when a custom task on the user's
side is implemented they make their own dtd for their task(s) and put it in the
META-INF directory to be picked up by our editor. I have already modified the
AntStructure to be able to separate the Core tasks in one dtd, and the Optional
tasks in another dtd so we have that piece done already (I would just have to
submit it for inclusion in the main Ant project). We could modify it to create
a dtd based upon classes found in a specific jar file rather than all classes
found on the classpath to accomodate the end user's creation of their own dtds.
If this sounds like something you would agree with please let me know and I
will get started. If not let's discuss what would be better.
Thanks,
Craig
>>> [EMAIL PROTECTED] 12/3/2002 3:07:45 AM >>>
Hi Craig (and all people interested and still lurking: Nick, Sim???)!
> I noticed that you committed something for Antidote. I was
> wondering if you could take a look at Bug 14138
> (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14138)
> where I have requested a few enhancements to Antidote, but
> haven't heard anything from anybody on where this is headed,
> or what more I need to do to get this committed.
I took a look into it closely and recognized, that it is the same
implementation you showed me some time ago. We agreed way back when that the
implementation is nice but pretty slow, so that we'll start enhancing
Antidote in small steps based upon the current CVS tree!
Anyways: If you still want to contribute, there are quite some things to do!
1. Find a concept for ACSDtdElement(s) to be rendered with different icons
in the tree, based upon the current implementation.
2. Build a DTD generator for ant.jar and optional.jar and/or an
introspection addition to support custom tasks without loosing the
performance of the current DTD-based implementation.
3. Wizard to create initial projects with default tempolates.
4. Custom editors
5. nicer looks. :)
6. JavaHelp (As you proposed)
7. the other things you proposed like persistable user settings etc.
> Thanks for looking into this for me,
> Craig
Wou are welcome :)
Cheers,
Chris
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
