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]>
