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)....
sim
--
Mustard Seed Software
mailto:[EMAIL PROTECTED]
