On Thu, 08 Mar 2001 13:15:25 +1100, Peter Donald wrote:
>At 05:45 7/3/01 -0800, David Rees wrote:
...
>
>>I think we need to look at better understanding the fact
>>that the attribute/element is very blurred in XML and that Ant blurs
>>it much more. We need to support a common way for indicating either
>>will work in a Task. Includes being good example. Do we even really
>>need a element for that, or could we support
>>setIncludes(String aString)
>
>Well I agree though I would do it like
>
>setInclude( IncludeEntry[] entrys );
>
>because include will most likely have multiple attributes. We could still
>support
>
><mytask include="**/*.java" />
>
>my implementing converters that convert from string to IncludeEntry type.
>(A feature that is much requested in certain domains like web-site
>development).
>
>so
>
><mytask include="**/*.java" />
><mytask>
> <include name="**/*.java" />
></mytask>
><mytask include="${myinclude}" />
>
>would be identical (assuming myinclude refers to an include datatype). They
>would all end up doing roughly
>
>setInclude( new IncludeEntry[] { new IncludeEntry( "**/*.java" ) } );
>
I definitely agree with this, but I am thinking that we need be more
generic for set vs. single. Something like:
setInclude(AnObject obj);
setIncludeSet(AntSet aSetOfAnObjs)
We shouldn't need to create AntSets for everything we support more
than one of.
And I still like the idea of a simple task supporting
setInclude(AnObject obj) and Ant (or some batch task :)?) iterating
through the values. Then is someone writes a reverse task to reverse
the contents of a file he can just write code that supports
setFile(File aFile)
and the code (or the developer) doesn't have to know anything about
AntSets. And yet the following would all work:
<Reverse file="c:\temp\text.txt" \>
<Reverse file="c:\temp\text.txt;c:\temp\text2.txt" \>
<Reverse>
<FileSet dir="c:\temp\" />
</Reverse>
<Reverse>
<ZipSet dir="c:\temp\" />
</Reverse>
<Reverse>
<FileListSet file="c:\temp\fileslist.txt" />
</Reverse>
Of course, the last two should be supported anyway by inheritance
(IMHO).
d
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
