Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 82845 invoked from network); 9 Mar 2002 08:39:55 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 9 Mar 2002 08:39:55 -0000 Received: (qmail 22137 invoked by uid 97); 9 Mar 2002 08:40:03 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 22087 invoked by uid 97); 9 Mar 2002 08:40:02 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 22076 invoked from network); 9 Mar 2002 08:40:01 -0000 Message-ID: <00be01c1c744$ff6558a0$0100a8c0@jose> From: "Jose Alberto Fernandez" To: "Ant Developers List" References: Subject: Re: [PROPOSE] task parameters that are only supplied when a property is defined Date: Sat, 9 Mar 2002 08:32:48 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N From: "Dominique Devienne" > 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 were = also > purposefully longish. I would just as well live with: >=20 > >=20 > Of course, I was thinking that ANT-core would take care of these = > sub-elements. --DD >=20 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: = or First I am proposing, for the attribute subelement, the name = "-attribute"=20 or "attribute-" to really try to use this as a new = pattern for the Introspector.=20 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 execution = and to control pattern s. Implementation wise, I think this can be done easily by the = Introspector.=20 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: 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]=20 > 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 >=20 > 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. =20 >=20 > The important thing is not to have to copy blocks of task code all = over > scripts just to parameterize certain attributes. >=20 > -----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 >=20 >=20 > Instead of this special syntax, how about being able to specify a = task's > attributes through sub-elements? The example from Steve = thus > becomes: >=20 > password=3D"secret" > rootlocalfolder=3D"C:\dev\buildtest\co"> > > > ignoreattributeifpropertynotdefined=3D"true" /> > >=20 > One can use the simple name/value attributes of 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 > ). >=20 > Of course, there are two drawbacks to this syntax: > 1) What happens with the attribute is specified both as an attribute, = and > through ? I'd say a build syntax error. > 2) Some tasks may already have an attribute sub-element? Maybe it = should be > or <${taskname}-attribute>, in = this > case? >=20 > This, if nothing else, has the merit of being more explicit that = $${lbl} or > $?{lbl} or whatever. Just my 2c. --DD >=20 > -----Original Message----- > From: Steve Cohen [mailto:SteveC@ignitesports.com]=20 > 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 >=20 > 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. >=20 > What if there were a convenient syntax within ant for specifying task > attributes based on properties=20 >=20 > such that >=20 > if the property were not set=20 > the task code would never see the attribute? >=20 > In other words, for example, look at this call: > username=3D"auser" > password=3D"secret" > rootlocalfolder=3D"C:\dev\buildtest\co" > forced=3D"true"=20 > label =3D "${lbl}" =20 > /> >=20 > 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. >=20 > 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). >=20 > Using this syntax, the above example becomes: >=20 > username=3D"auser" > password=3D"secret" > rootlocalfolder=3D"C:\dev\buildtest\co" > forced=3D"true"=20 > label =3D "$${lbl}" =20 > /> >=20 > My proposal is that this syntax be interpreted this way: >=20 > 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. >=20 > 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. >=20 >=20 >=20 >=20 >=20 > -- > To unsubscribe, e-mail: = > For additional commands, e-mail: = >=20 > -- > To unsubscribe, e-mail: = > For additional commands, e-mail: = >=20 >=20 > -- > To unsubscribe, e-mail: = > For additional commands, e-mail: = >=20 > -- > To unsubscribe, e-mail: = > For additional commands, e-mail: = -- To unsubscribe, e-mail: For additional commands, e-mail: