ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Simeon H.K. Fitch" <>
Subject Re: From attributes to elements and other concerns
Date Tue, 28 Nov 2000 01:53:04 GMT
On Mon, Nov 27, 2000 at 12:33:13PM -0800, Jose Alberto Fernandez wrote:
> Maybe the problem is that we have been too militant about having only one
> way
> to do anything. Militant to the point of user unfriendlyness.

I think this is a really good point, as I think it is so tempting to
select the approach (or militant stance as the case may be) that is
easiest to maintain, rather than remembering to think about multiple
end-user options. Someone (sorry that I forget who) made the
recommendation that if an element has a property that can have zero or
one values, then make it an attribute. If the property can have any
number of values, then defined it by sub-elements. Maybe the way we
should start thinking about some of the task definitions is that if a
property can have zero or many values, then allow attribute use for
the single value case, and sub-elements for the many values case.

(Did any of that make sense? 8^P )

> We could provide some common shortcuts for easy use. Ideally I would like
> them to be defined just with a composite <taskdef> declaration, but if not
> possible then allow for some extra java code.
>  <taskdef name="copydir" attributes="src,dest" >
>    <copy todir="${copydir.dest}" >
>      <fileset dir="${copydir.src} />
>    </copy>
>  </taskdef>
>  ...
>  <copydir src="foo" dest="bar" />
> Maybe we should call this an <aliasdef> instead of a real <taskdef>.
> Oh, I keep on dreaming....

Whoah! That's a cool way of looking at it! How long before you post
the patch for <aliasdef>? 8-]

I wonder if many of the arguments for scripting could be solved in
similar ways (i.e. declaration through basic primitives rather than
behavior definition with higher-level constructs)....


Mustard Seed Software

View raw message