From ant-dev-return-27522-qmlist-jakarta-archive-ant-dev=jakarta.apache.org@jakarta.apache.org Sat Mar 09 04:49:04 2002 Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 22606 invoked from network); 9 Mar 2002 04:49:04 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 9 Mar 2002 04:49:04 -0000 Received: (qmail 6982 invoked by uid 97); 9 Mar 2002 04:49:10 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 6927 invoked by uid 97); 9 Mar 2002 04:49:09 -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 6915 invoked from network); 9 Mar 2002 04:49:08 -0000 Message-ID: <3C89943F.65B527D9@progress.com> Date: Fri, 08 Mar 2002 23:49:03 -0500 From: "Bill Burton" Organization: Progress Software Corporation X-Mailer: Mozilla 4.76 [en] (Windows NT 5.0; U) X-Accept-Language: en-US MIME-Version: 1.0 To: Ant Developers List Subject: Re: [PROPOSE] task parameters that are only supplied when a property is defined References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N Hello, Steve Cohen wrote: > > See, now that I have looked more closely at it, I am veering back to my original idea, which sounds similar to what you've implemented in the Velocity template language (which I know nothing about other than what you describe here). Well, not implemented by me. It's just a rather awsome generic templating engine used for a multitude of things some web based and some not. > I tried to implement checking for "${" in the stcheckout task and before evencompiling, I find that I instantly don't like it. I want the user to be obligated to indicate his desire that for THIS PROPERTY INVOCATION ONLY, he does not want the default behavior of passing in the property expression. Yes, as you discovered, that's not the way to do it. > The trouble with checking for "${" in the task (or in the project for that matter) is that then you're saying you always want to do this for this attribute. Most of the time, though, that won't be the case. I WANT simple mistakes in typing the property name to cause errors. That is different from the case where I recognize the parameter may be defined or undefined and there is correct handling in either case. > > The only way to have it both ways is with some difference in syntax, whether it be my original syntax or the very similar syntax that Bill proposes, or perhaps, for those who find this kind of syntax too abstruse or "perl-like", Well the existing property expansion syntax is already Perl or shell-like. What's one more character? For this Quiet Notation syntax, it must be substantially similar to the existing proporty syntax starting with "$" and using "{...}" to bracket the property name. Otherwise, it will be too confusing and there may be additional escaping issues to deal with. So the only two ways I can see to use this type of notation are: $!{nullprop} - Like Velocity or $?{nullprop} - ? implies a question, i.e. maybe it's defined? > then something like the more explicit idea that Dominique proposed earlier. That approach could work for task level attributes with the caveat's already mentioned but would not work for attributes within nested elements unless Datatype and related classes are modified to support the nested element. It all seems too complicated to me and there's no way it could happen before Ant2 unless supported by individual tasks. > I don't object to the ProjectHelper idea of setting project-wide default policies, but I feel the build script writer should be given the option of overriding these defaults on a case-by-case basis. The script writer should be able to easily write a script that does it this way over here and that way over there. Agreed. > Using the explicit syntax is a way for the build writer to say "I know that this property may not be defined in this situation and that's a good thing, because it makes my script usable in two different ways." Whereas in other situations there's no such need and the normal property invocation is more appropriate. Yes, it seems to be the best of both worlds. -Bill > > -----Original Message----- > From: Bill Burton [mailto:billb@progress.com] > Sent: Fri 3/8/2002 5:31 PM > To: Ant Developers List > Cc: > Subject: Re: [PROPOSE] task parameters that are only supplied when a property is defined > > Hello, > > The Velocity template language has the exact same issue in not displaying > something when it's null. The default behavior is exactly like Ant where > null properties are rendered with the original text. However for cases > where you want null values to display as blank, it uses the ! character to > enable this "Quiet Notation functionality." So where you would normally > specify: > ${email} (or $email) > specfying, > $!{email} (or $!email) > returns blank when the reference is null. > > You can read about this at > http://jakarta.apache.org/velocity/user-guide.html#Quiet%20Reference%20Notation. > > In Ant, this could work exactly the same way: > username="auser" > password="secret" > rootlocalfolder="C:\dev\buildtest\co" > forced="true" > label = "$!{lbl}" > /> > > If the ${lbl} property isn't defined, "" would be passed. Howvever, tasks > would have to know to check for "" and treat it the same as not setting > the attribute at all. Many may do this already but others may throw a > BuildException instead. > > To support this scheme would require some modifications to ProjectHelper > replaceProperties and parsePropertyString methods to check for $! in > addition to $, handling $! properties as blank. Such changes would be > entirely backward compatible current behavior. > > Running older versions of Ant on a build file using this "Quiet Notation" > would give almost exactly the same functionality as now when a property is > undefined with the exception that no warning will be output and that the > unevaluated property would have the value of "$!{nullprop}" instead of > "${nullprop}". > > In of itself, the above modifications alone will not completely solve the > problem as an attribute may still be called with a blank value but it > would still be very useful in a significant number of cases. Over time, > tasks could be modified to support ignoring attributes with blank values > where appropriate provided this doesn't affect backward compatibility. > > The nice thing about this enhancement is it doesn't fundamentally change > Ant's syntax in any way and is nearly 100% backwards compatible with > version 1.4. > > -Bill > > Steve Cohen wrote: > > > > 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: > > > 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: > > > > > 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: For additional commands, e-mail: