Hi,
Thanks for your thoughts (and possible contributions). Here some further ideas.
In the past the Velocity design avoided by all means to become Perl like. Since there is
a simpler workaround, I believe a "~=" operator can be avoided (in Perl it
would mean to be a pattern matcher). So please use:
#if($foo == null)#set($foo = "bar")#end
or (using a context tool in the context):
#if(!$context.isKey($foo))#set($foo = "bar")#end
or wrap the above in a macro and use it:
#optionalDefault($foo "bar")
On the null reference issue, I proposed in an early Velocity to allow a silent
assign notation, in the line of:
#set($!foo = null)
to allow foo=null and to not log anything. This approach would allow the
designer to specify where he expects nulls to go through. Unhappily it
overlapped with another patch and did not make it into the core. To my
knowledge since velocity 1.6 (1.5?) a null value can be assigned to a context
key, when enabled by a property.
Currently the notation
#set($foo = $!bar.baz)
should not log if baz is undefined. You should also consider this silent
notation operator in your object check.
Combining this with my proposed syntax:
#set($!foo = $!bar.baz)
means to not complain that baz is null and silently assign it to the $foo in
the context.
Regards,
Christoph
Byron Foster wrote:
I've got a patch that checks property calls on objects, and throws a
MethodInvocationException when the property doesn't exist. However,
this really isn't a complete solution. This mode should also check
that variables are defined. Otherwise, you get the following strange
behavior that $foo.bar will throw an exception if the bar property
does not exist, but if foo is not defined, then nothing happens with
$foo.bar, which I think is unexpected behavior. Also, I think
variables should be checked for the same reasons as methods, mainly
that an undefined variable is probably a typo.
This leads to the next change. Variables should be able to contain
null values, otherwise it's impossible to distinguish between a
variable that is null, and a variable that is not defined. This
should have no impact on how Velocity works now since the
VelocityContext returns null in the case that a variable is null, and
a variable is not in the hash. I can provide a patch for these
changes also.
In the context of not allowing defined variables it would be nice to
be able to set a variable only when it is undefined. I was thinking of
a syntax like #set($foo ~= "bar"). This gives the developer the
ability to define default parameters to templates, and in some
contexts this may be necessary. This also provides an easy mechanism
for people who are converting existing templates over to the stricter
reference mode since they could define these #set statements for any
variables which are referenced in a template, but are not always
defined. I'm not sure what is involved in making this change...
Is this something appropriate for a beta build? I feel that maybe just
the method checking is half working... And then when variables are
added that's just another option to be set. Thoughts?
On Sep 27, 2008, at 10:26 , Nathan Bubna wrote:
This issue is still slated for 1.6, but no patches have yet been
contributed, nor has any committer taken the issue up yet. Help would
be appreciated, of course. :)
On Sat, Sep 27, 2008 at 4:39 AM, Byron Foster <[EMAIL PROTECTED]> wrote:
Hello, I was wondering if the issue
https://issues.apache.org/jira/browse/VELOCITY-553 was something
that was
slated for velocity 1.6. Or, if there are any settings in 1.6
which would
force velocity to throw an exception if an object does not have a
given
property?
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
