I don't see why you use <typedef> in this case. If <pcli> uses
DynamicConfigurator, then simply add/implement in <pcli> a <commanddef>
element (probably directly using addCommandDef() instead of using the
DynaConf) to enable the mapping of command name to classname. You could even
default map the command name by first looking into your command impl
package, capitalizing the first letter of the command. That way, no mapping
needed for your command, and still extensible is someone wants to write his
own command.
<typedef> is for DataTypes IMO, not to hold a simple name/classname mapping,
even though it can be (ab)used that way. Your example thus becomes:
<pcli>
<commanddef name="get"
classname="com.ncs.es.emsbe.tasks.pvcs.Get" />
<commanddef name="command"
classname="com.ncs.es.emsbe.tasks.pvcs.Command" />
<get destdir="/mydest">
<project name="/first/project" />
<project name="/second/project" />
</get>
<command name="myCommand"
extraArgs=" -a -b -c" />
</pcli>
without default mapping, and:
<pcli>
<get destdir="/mydest">
<project name="/first/project" />
<project name="/second/project" />
</get>
<command name="myCommand"
extraArgs=" -a -b -c" />
</pcli>
default mapping. Just my (unsolicited ;-) $0.02. --DD
-----Original Message-----
From: Shackelford, John-Mason [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 21, 2002 4:23 PM
To: 'Ant Users List'
Subject: RE: polymorphic data types as nested elements
Erik,
> I can't quite follow the details of what you're trying to
> build exactly
I won't waste more of your time on this as I think I am on the right track.
For the sake of providing an example (possibly a lousy one) to others
working on a similiar project I will summarize what I have been trying to
achieve and how I think I can get there using the DynamicConfigurator
interface.
I am rewriting the PVCS task. The top level task is a command processor that
does not know anything about the commands it executes other than that they
conform to the PCLICommand interface (abstractly implemented by
AbstractCommand which subclasses DataType). Specific commands, Get for
instance, subclass AbstractCommand.
<typedef name="get" classname="com.ncs.es.emsbe.tasks.pvcs.Get"/>
<typedef name="command" classname="com.ncs.es.emsbe.tasks.pvcs.Command"/>
<pcli>
<get destdir="/mydest">
<project name="/first/project"/>
<project name="/second/project"/>
</get>
<command name="myCommand" extraArgs=" -a -b -c"/>
</pcli>
Since I don't want my PCLI class to know anything about the concrete command
classes, I use the DynamicConfigurator to instantiate the appropriate
command based on element name.
public Object createDynamicElement(String name) throws BuildException {
String dataTypeFQN = (String)
getProject().getDataTypeDefinitions().get(name);
Object obj;
try {
Class c = Class.forName(dataTypeFQN);
obj = c.newInstance();
} catch (Exception e) {
throw new BuildException("Element " + name + " not supported.");
}
// make sure we have a command object
if (!(obj instanceof PCLICommand))
throw new BuildException(
"Element " + name + " is not a PCLI command and cannot be
executed.");
return obj;
}
John-Mason Shackelford
Software Developer
NCS Pearson - Measurement Services
2510 North Dodge St.
Iowa City, IA 52245
319-354-9200x6214
[EMAIL PROTECTED]
****************************************************************************
This email may contain confidential material.
If you were not an intended recipient,
Please notify the sender and delete all copies.
We may monitor email to and from our network.
****************************************************************************
--
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]>
