Adam, I think, is referring to the FilterReader codebase. FilterReader used to have a generic interface alone - but after the discussion we had with cullers where you were of the opinion that Ant cullers need not be limited to the same syntax as user defined ones, I refactored FilterReader to allow 'smart' syntax for Ant recognized filters while user defined ones will have to put up with the 'generic' syntax. However, all filters can be defined using the 'generic' syntax as well - just like the example you gave for filenameselector. User can define nested <param> elements to pass parameters to the filterreader (or selector).
Ahh, excellent idea. Much cleaner and more sensible.
Apologies for having missed the discussion on that. I saw that it was going on, but I skipped over it due to a lack of time recently (and I've never used FilterReaders). I'll go back and reread the threads now.
I'll also go over the proposal code and see what I can do to make them more orthagonal.
Naming the class attribute (of selectordef) as classname is an informal standard that is followed.
Sounds sensible. I'll change it.
After a quick glance over your code, it looks like you don't have a <filterdef> but instead define the classname as an attribute of the filter itself. This seems sensible to me. As a matter of fact, I found <selectordef> a bit of a pain to use because you couldn't refer to it in the same <extendselect> that you defined it. I think I should drop <selectordef> altogether unless there are objections. Just say, as <filterreader> does, that classname is a required attribute.
You would also need a <classpath> element for <selectordef> so that user can specify location of selector class which is not necessarily in the classpath when Ant was launched.
Good point.
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
