On Friday 25 April 2003 08:31, Stefan Bodewig wrote:
> On Thu, 24 Apr 2003, Costin Manolache <[EMAIL PROTECTED]> wrote:
> > Look - adding "roles" concept to ant, and adding antlib are 2
> > separate issues.
+1
>
> I tend to agree - that's why I proposed to get antlib into the main
> trunk with support for types and tasks only. At least for starters.
>
> If you want a custom mapper you can do so right now with a data type
> and refid. The same is not true for filter readers, conditions or
> selectors. But I feel that enabling that would inevitably lead us to
Not quite true for filter readers.
In CVS HEAD, FilterChain has a currently (deliberate) undocumented feature of
implementing DynamicConfigurator. The implementation looks up the
name in the types and if present and if the bean implements ChainableReader
it is used as a ChainableReader.
This is used to support ScriptFilter. Script reader is an optional
ChainableReader which depends on the presence of BSF and thus cannot
be implemented in the same way as the other built-in ChainableReaders.
> the more general polymorphism discussion and this is what I wanted to
> avoid 8-).
I have implemented a generalization of FilterChain's
usage of DynamicConfigurator in IntrospectionHelper.
This extends the introspection support to include methods of the form:
public void dynamicElement(<type> name);
So in my local ant build the relavant part of FilterChain.java is
public void dynamicElement(ChainableReader reader) {
filterReaders.addElement(reader);
}
and of ConditionBase.java
public void dynamicElement(Condition condition) {
conditions.addElement(condition);
}
--------------------------------------------------------
As regards using roles:
(note: Roles in the antlib proposal are not completely implemented,ie.
there is no condition, mapper or filter implementation so
my comments may be correct).
Roles in the proposal provide three features:
1) they provide a way of limiting the scope of the tag. I assume that
this is meant to be used by introspection in the same way as
the dynamicElement method above.
2) As a consequence of 1), the same identifier by be used to
point to different classes.
3) they provide an optional adaptor to allow classes that do not support
a requred interface.
These features may be implemented in different ways, for example:
typedef could be extended to have an implements attribute:
<typedef name="and" classname="o.a.t.ant.taskdefs.conditions.And"
implements="o.a.t.ant.taskdefs.conditions.Condition"/>
"and" may then only be used in beans that have the method:
public void dynamicElement(Condition condition)
if the class did not implement the condition, a proxy class could be defined:
<typedef name="diskfull" classname="acme.disk.DiskFull"
implements="o.a.t.ant.taskdefs.conditions.Condition"
proxy="acme.ant.ConditionAdaptor"/>
or one could have a class that defines adaptors:
a new task may define adaptors:
<adaptor classname="o.a.t.ant.taskdefs.conditions.Condition"
proxy="acme.ant.ConditionAdaptor"/>
--------------------------------------------------------
My feeling is that roles are not needed to support dynamic conditions,
filters ...,
in fact I do not think that typedef is needed:
<loadclasses classpathref="${acme.ant.jars}"/>
<condition property="disk.danger.level">
<acme.disk.DiskFull percent="70" filesystem="/tmp"/>
</condition>
I see typedef/taskdef as providing alaises for java beans.
Peter.
