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:
<stcheckout URL="STARTEAM:49201/Aproject/AView"
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:
> <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:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
