ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jose Alberto Fernandez" <j_a_fernan...@yahoo.com>
Subject Re: [PROPOSE] task parameters that are only supplied when a property is defined
Date Sat, 09 Mar 2002 08:32:48 GMT
From: "Dominique Devienne" <DDevienne@lgc.com>

> Yes, it is more wordy, on purpose, so it follows ANT's Understandability
> goal (Ant must be clearly understandible for a first time as well as a
> veteran user), and the attribute names chosen for <attribute> were also
> purposefully longish. I would just as well live with:
> 
> <attribute name="label" property="lbl" ignoreifnotset="true" />
> 
> Of course, I was thinking that ANT-core would take care of these <attribute>
> sub-elements. --DD
> 

I think the concept is not that bad. It reminds me of working in XSLT (which I have been
doing alot lately) :-)

However, the construct as defined is not antish enough, IMHO; and it seem too specific to
your very particular situation. How about something like:

    <stcheckout-attribute name="label" value="${lbl}" if="lbl" /> or
    <attribute-lable value="${lbl}" if="lbl" />

First I am proposing, for the attribute subelement, the name "<elementName>-attribute"

or "attribute-<attributeName>" to really try to use this as a new pattern for the Introspector.

It should be an easy pattern to understand and to process.

Second, you can pass a "value" which can be anything, not just the plain property but maybe
some more complex expression based on the property, perhaps.

Third, use "if" and/or "unless", optionally, to control whether the attribute declaration
should go in
or not. This is the same mechanism used to control <target> execution and to control
pattern <exclude>s.

Implementation wise, I think this can be done easily by the Introspector. 
Thinking about it, the second form may be even simpler because Introspector does not need
to know
about the name of the element, all information is local. The second form also disallows dynamic
binding constructs which can be difficult to trak:

    <stcheckout-attribute name="${label}" value="${lbl}" if="lbl" />

above, even the name of the attribute we are talking about is dynamically defined, which is
kind of extrange.

Well enough about that.

Jose Alberto

>  -----Original Message-----
> From: Steve Cohen [mailto:SteveC@ignitesports.com] 
> Sent: Friday, March 08, 2002 11:36 AM
> To: Ant Developers List
> Subject: RE: [PROPOSE] task parameters that are only supplied when a
> property is defined
> 
> That's a little (a lot?) more wordy, but I wouldn't mind it as long as ANT
> handled it rather than each task.  I don't think we would want to rewrite
> every task to handle this.  
> 
> The important thing is not to have to copy blocks of task code all over
> scripts just to parameterize certain attributes.
> 
> -----Original Message-----
> From: Dominique Devienne [mailto:DDevienne@lgc.com]
> Sent: Friday, March 08, 2002 11:08 AM
> To: 'Ant Developers List'
> Subject: RE: [PROPOSE] task parameters that are only supplied when a
> property is defined
> 
> 
> Instead of this special syntax, how about being able to specify a task's
> attributes through <attribute> sub-elements? The example from Steve thus
> becomes:
> 
>   <stcheckout username="auser"
>                      password="secret"
>                      rootlocalfolder="C:\dev\buildtest\co">
>     <attribute name="URL" value="${starteam-url}" />
>     <attribute name="forced" value="true" />
>     <attribute name="label" valuefromproperty="lbl"
> ignoreattributeifpropertynotdefined="true" />
>   </stcheckout>
> 
> One can use the simple name/value attributes of <attribute> to specify the
> task attribute as always (using literals or properties), and one can have
> more specific ways to use attribute as shown above (which works kind of like
> <propertycopy>).
> 
> Of course, there are two drawbacks to this syntax:
> 1) What happens with the attribute is specified both as an attribute, and
> through <attribute>? I'd say a build syntax error.
> 2) Some tasks may already have an attribute sub-element? Maybe it should be
> <task-attribute> or <${taskname}-attribute>, <stcheckout-attribute>
in this
> case?
> 
> This, if nothing else, has the merit of being more explicit that $${lbl} or
> $?{lbl} or whatever. Just my 2c. --DD
> 
>  -----Original Message-----
> From: Steve Cohen [mailto:SteveC@ignitesports.com] 
> Sent: Friday, March 08, 2002 10:53 AM
> To: ant-dev@jakarta.apache.org
> Subject: [PROPOSE] task parameters that are only supplied when a
> property is defined
> 
> I previously sent this idea in a message whose title may have hidden its
> importance, but this is an idea I'd really like to see and I'd like the
> developers to comment on it.
> 
> What if there were a convenient syntax within ant for specifying task
> attributes based on properties 
> 
> such that
> 
> if the property were not set 
> the task code would never see the attribute?
> 
> In other words, for example, look at this call:
>   <stcheckout URL="STARTEAM:49201/Aproject/AView"
>      username="auser"
>      password="secret"
>      rootlocalfolder="C:\dev\buildtest\co"
>      forced="true" 
>      label = "${lbl}"  
>   />
> 
> If the lbl property is defined, the task will get its value as the label
> attribute.  But if the lbl property is not defined, the task will get the
> text "${lbl}" and most likely fail.
> 
> I am proposing a new syntax that would allow a property to be specified with
> a different meaning.  Let's say this syntax is two dollar signs instead of
> one ($${property}).  (This may not be the optimal symbol for the ant parser,
> but that is a detail - I am not wedded to any symbol).
> 
> Using this syntax, the above example becomes:
> 
>   <stcheckout URL="STARTEAM:49201/Aproject/AView"
>      username="auser"
>      password="secret"
>      rootlocalfolder="C:\dev\buildtest\co"
>      forced="true" 
>      label = "$${lbl}"  
>   />
> 
> My proposal is that this syntax be interpreted this way:
> 
> If the property lbl is defined, treat $${lbl} exactly as ${lbl} but
> if the property lbl is not defined, do not even pass the label attribute to
> the task.
> 
> It seems to me that this would allow for much more flexible scripts,
> especially when more than one parameter of a task is optional and there are
> different use cases for the task.  In the above example, to get the variable
> functionality desired, I must include two blocks in my script, one with the
> label attribute defined and the other without it, and put it some
> conditionals to direct the processing to the right place.  This can get
> clumsy, especially if there are several attributes to parameterize; the
> combinatorial possiblilities could be large, making for scripts that are
> harder to understand or maintain.
> 
> 
> 
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
> 
> --
> To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
> 
> 
> --
> To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>
> 
> --
> To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


--
To unsubscribe, e-mail:   <mailto:ant-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:ant-dev-help@jakarta.apache.org>


Mime
View raw message