On Wed, 20 Feb 2002, Conor MacNeill <[EMAIL PROTECTED]> wrote: > Let's agree on the concept of roles firstly then :-)
OK, I agree on it 8-) > What are the goals of defining and using roles? As far as I can see > this is to allow extensibility, primarily the ability to define new > nested elements for a task without changing the task. In the very first place, I'm with Adam here, roles just reflect that there will be more pluggable things than just tasks and data types in later version of the descriptor. A way to define shortcuts, and to avoid hard coded names in the parser. I'm also more on the Myrmidon side of things as I understand from Adam's description, i.e. in the case of > <foo> > <bar> first look for addFoo. If you don't find anything, look for an add(SomeInterface) method and look up an element bar in the role of SomeInterface. I really would tie the role to the type of the thing to add - and therefore on the method signature when it comes to configuring - and not on an interface the parent element had to implement. I wouldn't even restrict it to interfaces. This is not compatible with Ant 1.x, I know, which also means that we cannot use that generalized mechanism to implement TaskContainer. But this is not the goal here, the goal is to start with a descriptor that replaces the property files - and do it in a way that allows us to keep the general format of the descriptor in the future. Putting in roles now wouldn't do much in the context of Ant 1.x, but may make it easier to extend the descriptor in the future. > To give an example using real Ant types. > <foo> > <fileset ant:type="zipfileset"> The example could be <role name="fileset" class="org.apache.ant.types.FileSet" /> <fileset name="zipfileset" class="org.apache.ant.types.ZipFileSet" /> in the descriptor and <foo> <zipfileset ...> where the task simply only had add(FileSet). Less typing for the build file writer 8-) and to me it seems to be as explicit as it needs to be. We may even be able to implement it that way in 1.x - just not to make TaskContainer use it that way. > The build file writer asks explicitly for the type they want, rather > than the background plumbing figuring it out. Humm, I'd expect that user'd be told in the documentation of the library, which contained ZipFileSet, that you can use it everywhere where the task documentation - any task documentation - says you can use a fileset. Stefan -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
