From attributes to elements and other concerns

[Peter Donald <do...@apache.org>]

Hi,

I just received a number of complaints/concerns about latest ant direction
from a number of relatively non-technical people (and as such I am not sure
if they are valid complaints). As ant has evolved there has been a tendency
to reduce the number of attributes in a task and increase the number of
elements. So parameters are gradually going from "include" attributes to
"include" elements. I was told that this is increasing difficult for
average users. While I tend to agree that it increases difficulty I think
it is a fair enough tradeoff for added power in general. It does increase
the learning curve a little but ...

Not sure - what does everyone else think ? Is it desirable to continue the
trend or not ? I would say tentatively that it is a desirable thing to
elementize tasks.


Cheers,

Pete

*------------------------------------------------------*
| Despite your efforts to be a romantic hero, you will |
| gradually evolve into a postmodern plot device.      |
*------------------------------------------------------*

Re: From attributes to elements and other concerns

["Craig R. McClanahan" <Cr...@eng.sun.com>]

Peter Donald wrote:

> Hi,
>
> I just received a number of complaints/concerns about latest ant direction
> from a number of relatively non-technical people (and as such I am not sure
> if they are valid complaints). As ant has evolved there has been a tendency
> to reduce the number of attributes in a task and increase the number of
> elements. So parameters are gradually going from "include" attributes to
> "include" elements. I was told that this is increasing difficult for
> average users. While I tend to agree that it increases difficulty I think
> it is a fair enough tradeoff for added power in general. It does increase
> the learning curve a little but ...
>
> Not sure - what does everyone else think ? Is it desirable to continue the
> trend or not ? I would say tentatively that it is a desirable thing to
> elementize tasks.
>

Interestingly, this question is not limited to just Ant.  It's a general design
issue for pretty much any XML-based data stream, and there are analogous issues
in other areas -- such as designing families of custom tags for JSP
environments.

It's probably because I look at the world from a "nested tree of objects" point
of view fairly often when designing such things, but I tend to start with the
following rule of thumb:

    If something must be specified exactly once,
    or can be specified at most once, make it an
    attribute.  If something can be specified more
    than once, make it an element (which is
    typically nested inside an "owning" element).

This principle has served me pretty well so far, and it tends to match what I
typically do when processing XML based stuff (attributes --> properties,
elements --> beans).  It also seems to be consistent with the path that Ant has
been taking lately, so it seems OK to me.

(Other than the fact that you make me change my build files every blasted
version, of course :-)

>
> Cheers,
>
> Pete
>

Craig McClanahan

Re: From attributes to elements and other concerns

[Stefan Bodewig <bo...@apache.org>]

Peter Donald <do...@apache.org> wrote:

> I just received a number of complaints/concerns about latest ant
> direction from a number of relatively non-technical people (and as
> such I am not sure if they are valid complaints).

Too me they are valid. At least they don't become invalid just because
they are non-technical people 8-).

> As ant has evolved there has been a tendency to reduce the number of
> attributes in a task and increase the number of elements.

There are two sides of the coin. 

Talking about the file operations copy, move and delete, they have
become more complicated - but I don't see a way around that other than
removing the deprecation warnings from the old tasks and
reimplementing them in terms of the new tasks, something along the
line

Copydir:

protected Copy copy = new Copy();

public void setDest(File dest) {
    copy.setTodir(dest);
}

public void setSrc(File src) {
    FileSet fs = new FileSet();
    fs.setDir(src);
    copy.addFileset(fs);
}

public void execute() throws BuildException {
    copy.execute();
}

But I wouldn't really like this approach of providing tasks that are
nothing but shortcuts for another task. Actually, we do have a case
like this with antcall/ant.

In almost any other case, nested elements are probably easier too
understand than attributes, especially when it comes to
enumerations. Having lists separated by comma or space is far more
difficult to read than a number of separate elements IMHO - and makes
it impossible to include entries that contain commas or spaces.

Stefan