Quiet variables fail in "nested" directives?

[Dan Bradley <ja...@hotmail.com>]

I'm having trouble getting quiet variables to work in an unusual situation,
and I'm not sure if there's a way to do what I want to do, whether it's a
bug, or a feature.

Given one macro where the result is used as an argument in the call to
another, in the following fashion, as described at
http://jakarta.apache.org/velocity/user-guide.html#Velocimacro%20Miscellany:

#macro (tablerow $arg)
<tr><td>$arg</td></tr>
#end

#macro (txtinput $name $value)
<input type="text" name="$name" value="$value">
#end

<table>
#tablerow("#txtinput ('email', $!email)")
</table>

If $email is in the context the HTML is generated as expected and desired,
i.e.:
<tr><td><input type="text" name="email" value="me@somewhere.com"></td></tr>

However, if $email is not in the context, the variable does not fail quietly
creating value="", the desired result, but instead is passed through as
value="$!email", so I end up with:
<tr><td><input type="text" name="email" value="$!email"></td></tr>

I have tried various combinations of $email, $!email, $!{email}, in single
quotes and without, all to no avail. The reason I want to do this is so that
the input fields in a form page will be blank if no information has been
submitted yet, but filled in if it has been submitted, without creating two
different versions of the page or doing an if/else check on each field.

Any ideas if there's an alternate way to do what I want to do, or if this is
in fact a bug? I suspect that it's the result of an intentional design
decision, but I don't quite understand what's going on under the hood well
enough to figure out how to make it work.

Thanks,

Dan Bradley
jackbang@hotmail.com

--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

Re: Quiet variables fail in "nested" directives?

["Geir Magnusson Jr." <ge...@optonline.net>]

On 12/6/01 10:10 PM, "Dan Bradley" <ja...@hotmail.com> wrote:

> I'm having trouble getting quiet variables to work in an unusual situation,
> and I'm not sure if there's a way to do what I want to do, whether it's a
> bug, or a feature.
> 
> Given one macro where the result is used as an argument in the call to
> another, in the following fashion, as described at
> http://jakarta.apache.org/velocity/user-guide.html#Velocimacro%20Miscellany:
> 
> #macro (tablerow $arg)
> <tr><td>$arg</td></tr>
> #end
> 
> #macro (txtinput $name $value)
> <input type="text" name="$name" value="$value">
> #end
> 
> <table>
> #tablerow("#txtinput ('email', $!email)")
> </table>
> 
> If $email is in the context the HTML is generated as expected and desired,
> i.e.:
> <tr><td><input type="text" name="email" value="me@somewhere.com"></td></tr>
> 
> However, if $email is not in the context, the variable does not fail quietly
> creating value="", the desired result, but instead is passed through as
> value="$!email", so I end up with:
> <tr><td><input type="text" name="email" value="$!email"></td></tr>

Heh.  This is an interesting one.

I think I know what it is, and will take a look.  However, I think that
passing $!email and expecting it to work this way is incorrect.  It's
accepted by Velocity, but shouldn't be.

What's the correct behavior?

Note that $!email doesn't require it to 'fail' quietly, but actually render
itself quietly - i.e. If no value in the context, don't render.

But being a VM arg is subtly different.  I describe VMs as 'passing by
name', so I guess that the worst it should do is render as $email...  ?

Another way - does the 'quietness' of the arg trump the way the #macro() was
designed to render things?  I think not, but am interested in what others
think.

What I think you should do is put the quiet reference in the VM :

#macro( txtinput $name $value )
  <input type="text" name="$name" value='$!value'>
#end


Does that help (for now) ?


> 
> I have tried various combinations of $email, $!email, $!{email}, in single
> quotes and without, all to no avail. The reason I want to do this is so that
> the input fields in a form page will be blank if no information has been
> submitted yet, but filled in if it has been submitted, without creating two
> different versions of the page or doing an if/else check on each field.
> 
> Any ideas if there's an alternate way to do what I want to do, or if this is
> in fact a bug? I suspect that it's the result of an intentional design
> decision, but I don't quite understand what's going on under the hood well
> enough to figure out how to make it work.

It is intentional, the pass by name thing.  However, if we can decide on the
appropos behavior for this 'edge case', then we can fix it.

-- 
Geir Magnusson Jr.                       geirm@optonline.net
System and Software Consulting
You're going to end up getting pissed at your software
anyway, so you might as well not pay for it. Try Open Source.



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>