Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Ant Developers List" <ant-dev@jakarta.apache.org>
Message-Id: <sdec8665.001@prv-mail20.provo.novell.com>
Date: Tue, 03 Dec 2002 10:24:50 -0700
From: "Craig Campbell" <ccampbell@novell.com>
To: <ant-dev@jakarta.apache.org>
Subject: [Antidote] ToDo
Mime-Version: 1.0
Content-Type: multipart/alternative; boundary="=_94C848C5.9CFDA585"

--=_94C848C5.9CFDA585
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Christoph and all interested,
=20
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).
=20
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).
=20
=20
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 =3D (DOMAttributes)value;
=20
        // Disable event generation.
        _squelchChangeEvents =3D true;
=20
        // 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 =3D _prop2Editor.keySet().iterator();
        while(it.hasNext()) {
            PropertyDescriptor desc =3D (PropertyDescriptor) it.next();
            PropertyEditor editor =3D (PropertyEditor) _prop2Editor.get(des=
c);
=20
            String key =3D desc.getName();
            String attributeValue =3D _attributes.getProperty(key);
=20
            if(attributeValue =3D=3D null)  {
                if(!_attributes.containsKey(key))
                    _attributes.put(key, "");
            }
=20
            editor.setAsText(attributeValue);
        }
=20
        // Enable event generation.
        _squelchChangeEvents =3D false;
=20
    }
- 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.
=20
- 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).
=20
=20
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.
=20
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.
=20
Thanks,
Craig

>>> Christoph.Wilhelms@impress.com 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=20
> wondering if you could take a look at Bug 14138=20
> (http://nagoya.apache.org/bugzilla/show_bug.cgi?id=3D14138)=20
> where I have requested a few enhancements to Antidote, but=20
> haven't heard anything from anybody on where this is headed,=20
> 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:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


--=_94C848C5.9CFDA585--