DynamicConfigurator-Interface

[Ja...@rzf.fin-nrw.de]

When should I use that interface? I had a look at it (and the only
implementing class
I found was XSLTProcess.Factory.Attribute). I don´t see any requirement
for the Attribute-Class to implement that interface. So I ask myself - why
to implement it?


Jan Matèrne


-----Ursprüngliche Nachricht-----
Von: Erik Hatcher [mailto:jakarta-ant@ehatchersolutions.com]
Gesendet am: Dienstag, 21. Januar 2003 14:47
An: Ant Developers List
Betreff: Re: proposed patch to ANT SQL task

Paul,

Also, have a look at the DynamicConfigurator interface.  This would  
allow you to be completely dynamic about which attributes you accept.   
As stated though, be careful about which JDK you are relying on and  
that your code is backwards compatible to 1.1.

	Erik

Re: DynamicConfigurator-Interface

[Erik Hatcher <ja...@ehatchersolutions.com>]

Unfortunately it was added too late before the 1.5 feature cutoff to 
have any implementation within Ant's own codebase.  But XDoclet uses 
it, which allows for an extensible task facade for XDoclet's subtasks.  
A vendor could now write their own XDoclet module and simply dropping 
the JAR within the <taskdef> classpath the subtask becomes available... 
e.g.

	<ejbdoclet...>
        <someNewVendorSubTask..../>
    </ejbdoclet>

The <ejbdoclet> task implements DynamicConfigurator.  Before this 
addition, <ejbdoclet> would have to be hardcoded with a 
createSomeNewVendorSubTask (or add/addConfigured) method making it very 
rigid.

Ant's <ejbjar> task is a perfect candidate for this refactoring also.  
The tough part is coming up with the discovery mechanism.  The XDoclet 
team has a slick way of doing this by looking for XML descriptor files 
in the classpath, and plugin modules simply have to embed that within 
their JAR.

The same dynamic nature can be done with attributes, so setters for 
every attribute are not needed.

	<someTask attribute1="..." attribute2="...." ..../>

With no fixed setters for those attributes.  Perfect for the extended 
JDBC attributes, it seems, although a nested <attribute> element could 
be made to do a similar dynamic feature too.  It seems cleaner to 
express things with attributes with meaningful names though.

	Erik


On Tuesday, January 21, 2003, at 09:12  AM, Jan.Materne@rzf.fin-nrw.de 
wrote:
> When should I use that interface? I had a look at it (and the only
> implementing class
> I found was XSLTProcess.Factory.Attribute). I don´t see any requirement
> for the Attribute-Class to implement that interface. So I ask myself - 
> why
> to implement it?
>
>
> Jan Matèrne


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>