Erik,
I figured we could cross the "Tasks that don't inherit from Task" bridge when
we came to it, but the xdocs metadata appears to be a better choice. I will
look into it. How close is it to going live rather than just a proposal?
About the naming convention, would you believe that I saw the @tag but didn't
even think about using that. :-$
About the getXXX, setXXX, I believe that we definately need getters for every
setter, but for a gui such as Antidote we don't need getters for the
adders/creators, but it wouldn't be a bad programming practice to provide them.
Until we have that the mapping setters to properties has worked well enough to
allow a fully customizable editor for any task it can find the class for (I
have been using it for a couple of months now).
>>> [EMAIL PROTECTED] 12/3/2002 11:17:54 AM >>>
Craig Campbell wrote:
> 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).
Woah now! :)
Keep in mind that tasks don't necessarily extend from Task. Have a look
at the proposal/xdocs stuff (something I'm nearing to getting back into,
I promise!). It builds metadata files for each task using the real Ant
rules for what makes a task a "task", as well as using the real
IntrospectionHelper for determining what attributes and sub-elements
each task/datatype supports.
The idea is that the proposal/xdocs stuff will generate all the metadata
needed by Antidote, IDE's, and other tools that want to integrate with
Ant. Let's leverage that, unless there is a compelling reason not to.
> 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).
The task name information is available in the proposal/xdocs generated
data. Its either the lowercased version of the classname (minus the
"Task" suffix if its there) or based on an @tag that is present at the
class Javadoc level. Have a look at the source code to Ant's tasks and
you'll see this kind of thing there.
> - 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).
This keeps coming up. Perhaps tasks should have getters for all their
internal state... but then what about subelement information? getters
for all the adders/creators as well?
Erik
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
