ant-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shackelford, John-Mason" <Sha...@ncs.com>
Subject RE: polymorphic data types as nested elements
Date Fri, 23 Aug 2002 14:57:23 GMT
Erik, Dominique,

> I'm with Dominique here - why have DataType's in the 
> equation?  Do you plan on reusing them across multiple
> <pcli> invocations? If  not, then its way overkill.

Thanks. This is the sort of sensibility one only picks up with exposure to a
developer community. Thanks for taking time to point it out. I had just
figured that since a DataType make reusability possible and we might want
that feature at some point and since it doesn't seem to cost much either in
terms of coding effort or performance why not? But I suppose that this sort
of reasoning could lead to some sloppiness. 

I like XDoclet's use of a properties file to handle mapping, it frees the
user from having to think about it and yet remains extensible.

Thanks again, Erik and Dominique, for your mentoring.



John-Mason Shackelford

Software Developer
NCS Pearson - Measurement Services
2510 North Dodge St.
Iowa City, IA 52245
319-354-9200x6214
shacjo@ncs.com

> -----Original Message-----
> From: Erik Hatcher [mailto:jakarta-ant@ehatchersolutions.com]
> Sent: Thursday, August 22, 2002 5:16 AM
> To: Ant Users List
> Subject: Re: polymorphic data types as nested elements
> 
> 
> Shackelford, John-Mason wrote:
> > 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. 
> 
> Have you had a look at the other SCM tasks in the Ant codebase? 
> Clearcase and VSS, for example (and I'm sure others), have a 
> base Task 
> class that they extend.  So your pattern is a worthy improvement over 
> this, but a bit similar as well.
> 
> > <typedef name="get" classname="com.ncs.es.emsbe.tasks.pvcs.Get"/>
> > <typedef name="command" 
> classname="com.ncs.es.emsbe.tasks.pvcs.Command"/>
> 
> I'm with Dominique here - why have DataType's in the 
> equation?  Do you 
> plan on reusing them across multiple <pcli> invocations?  If 
> not, then 
> its way overkill.
> 
> > 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);
> 
> So, you're using datatypes simply to have a mapping of 
> name/classname. 
> I'd recommend you use some other design for this if this is the only 
> reason your using datatypes.  Look at XDoclet's CVS codebase and how 
> they have an XML descriptor in their META-INF folder of their 
> JAR files 
> that provides the lookups.
> 
> But regardless - you're definitely on a good track here.
> 
> >         //  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;
> >     }
> 
> Groovy.  You've got this part going nicely, and using the 
> datatype thing 
> is an interesting hack to get the lookups working.  
> Ingenious, in fact. 
>   But I still think its overloading and (ab)using (to borrow from 
> Dominique!) what a DataType is - unless of course you have plans for 
> reusability here somehow.
> 
> 	Erik
> 
> 
> --
> To unsubscribe, e-mail:   
<mailto:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>

**************************************************************************** 
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:ant-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-user-help@jakarta.apache.org>


Mime
View raw message