ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter reilly <peter.rei...@corvil.com>
Subject Re: Roles (was: antlib)
Date Tue, 29 Apr 2003 09:11:11 GMT
First, I must say that it would be nice to have
context dependent element names - my core example
is the element name "containsregexp" - is this a condition,
filter or selector ? , the different meaning  may mean
that different classes should implement them.

However, I think that expressing this in ant xml dialect is
difficult and would result in needless complexity and restrictions.
For example if the containsrexexp implemenations are project
components which one should be used at the top level?
<project ...>
   <containsregexp id="contains.script" .../>

Or the example I gave previously:

public class MyTask extends Task {
   public void add(FileSet fileset) {       filesets.add(fileset);    }
   public void add(ZipFileSet ignore) {
        throw new BuildException("Not able to deal with zipped files");
    }
}

does one need to do:
<role name="fileset" class="..FileSet"/>
<fileset name="fileset" class="...Fileset"/>
<fileset name="zipfileset" class ="...ZipFileSet"/>
<fileset name="libfileset" class="...LibFileSet"/>

and:
public class MyTask extends Task {
   public void add(FileSet fileset) {
       if (fileset instanceof ZipFileSet)
         throw new BuildException("Not able to deal with zipped files");
       filesets.add(fileset);   
   }
}

I think that having context dependent script defined names is a
bridge to far at this stage in ant's developement.

Having unique ant script defined name -> class is easy to use,
describe, implement and it is what ant does at the moment.

Adding context dependent names is not necessary to achieve the
goal of user defined conditions, selectors, filters, user classes.
(mappers are a little different as the current implemenation uses
attributes and not nested elements)

Peter

Some comments in-line
On Monday 28 April 2003 19:55, Jose Alberto Fernandez wrote:
> >
> > Use java rules, (try all interfaces)
>
> The parent will tell you what interfaces to use. No need for wild searches.

Sorry, when I said try all interfaces, I meant check the parent class
for all the interfaces/classes provides by the add() and addConfigured()
methods. This is not a wild search ;-)

>
> > > - addComponent( MyRole ) or addMyRole( MyRole ) or both ?
> > > I.e. a fixed-name method, with overloading to support
> >
> > multiple roles,
> >
> > > or one add method per role ?
> >
> > add(ElementClass) to be consistent with other ant method
> > matching patterns.
>
> I prefer just supporting addConfigured, the reason being that makes little
> sense passing a non configured object of an unknown implementation to the
> parent. What does it possible can do to it, before it gets configured?

It makes as much sense as the current differences between add<Name>() and
addConfigured<Name>(). I do not think that many people make use of the
differences (and the add<Name>() pattern is used by default).

Using add is usefull for containers to override defaults on contained objects
- for example
onError = new OnError("ignore")
void add(Definer definer) {
    definer.setOnError(onError);
    definers.add(definer);
}

The definer's object default onError may be "fail" , this would set it to
"ignore".

Peter

Mime
View raw message