You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by lloyd <su...@twilight-systems.com> on 2004/01/15 23:38:58 UTC
Re: POLL: null context attribute values
Mike Kienenberger wrote:
> The more I use Velocity, the more I find myself writing hacks to get around
> the inability of Velocity to handle nulls as a context attribute value.
>
> Over the last half-year I've been subscribed to the mailing list, I've seen
> comments that suggest the current behavior can't be changed because it'd
> break backwards compatiblity.
>
> Is there anyone on this mailing list that depends on context attributes not
> being set to null when the RHS evalutes to null?
>
> Or are we all silently suffering because of some mythical or implausible use
> case that doesn't exist?
i realize i'm coming to this a little late - what's the latest thinking
on it?
i agree 100% that the null values problem is a BIG impediment to writing
sane templates. i've been silent on the list for a long time because
velocity mostly gives me everything i need, but i'm working on a
template that works with a deeply hierarchical object, with a lot of
levels to iterate over, and *all* the elements at all levels can have
null values. lots of checks for nulls and #if blocks that contribute
nothing but confusion...
if a value is null, it should be *null*, not the previous value :-)
fix it and i'll never mention floats again! ( <-- pssst: liar )
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Jan 15, 2004, at 6:46 PM, lloyd wrote:
> Geir Magnusson Jr wrote:
>>> would this mean that
>>>
>>> #foreach( $lev1 in $topLevelItems )
>>> #if( $lev1 ) ## should return false if $lev1 is null?
>>> #set( $lowerLevelItems = $lev1.lowerLevelItems )
>>> #foreach( $lev2 in $lowerLevelItems )
>>> #if( $lev2 )
>>> ## etc
>>> #end
>>> #end
>>> #end
>>> #end
>>>
>>>
>>> ... would work as intuitively expected if $lev1 and $lev2
>>> occasionally contain nulls?
>> The only aspect that is what we are talking about is if $lev1 can be
>> assigned null in the #foreach() and I think it can't now because the
>> VelocityContext prohibits setting of null
>> We'd remove that.
>
> are you saying that the above should work now, or that making the
> above work isn't even under consideration? :-)
It would work in the Brave New World, because we'd allow $lev1 to be
set w/ a NULL (as well as $lev2), which they can't be now.
geir
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by lloyd <su...@twilight-systems.com>.
Geir Magnusson Jr wrote:
>> would this mean that
>>
>> #foreach( $lev1 in $topLevelItems )
>> #if( $lev1 ) ## should return false if $lev1 is null?
>> #set( $lowerLevelItems = $lev1.lowerLevelItems )
>> #foreach( $lev2 in $lowerLevelItems )
>> #if( $lev2 )
>> ## etc
>> #end
>> #end
>> #end
>> #end
>>
>>
>> ... would work as intuitively expected if $lev1 and $lev2 occasionally
>> contain nulls?
>
>
> The only aspect that is what we are talking about is if $lev1 can be
> assigned null in the #foreach() and I think it can't now because the
> VelocityContext prohibits setting of null
>
> We'd remove that.
are you saying that the above should work now, or that making the above
work isn't even under consideration? :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Jan 15, 2004, at 6:34 PM, lloyd wrote:
> Geir Magnusson Jr wrote:
>> Question : if #set could make LHS == null, would anything break in
>> existing templates? It's a one line fix if not... :)
>
> would this mean that
>
> #foreach( $lev1 in $topLevelItems )
> #if( $lev1 ) ## should return false if $lev1 is null?
> #set( $lowerLevelItems = $lev1.lowerLevelItems )
> #foreach( $lev2 in $lowerLevelItems )
> #if( $lev2 )
> ## etc
> #end
> #end
> #end
> #end
>
>
> ... would work as intuitively expected if $lev1 and $lev2 occasionally
> contain nulls?
The only aspect that is what we are talking about is if $lev1 can be
assigned null in the #foreach() and I think it can't now because the
VelocityContext prohibits setting of null
We'd remove that.
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by lloyd <su...@twilight-systems.com>.
Geir Magnusson Jr wrote:
> Question : if #set could make LHS == null, would anything break in
> existing templates? It's a one line fix if not... :)
would this mean that
#foreach( $lev1 in $topLevelItems )
#if( $lev1 ) ## should return false if $lev1 is null?
#set( $lowerLevelItems = $lev1.lowerLevelItems )
#foreach( $lev2 in $lowerLevelItems )
#if( $lev2 )
## etc
#end
#end
#end
#end
... would work as intuitively expected if $lev1 and $lev2 occasionally
contain nulls?
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by lloyd <su...@twilight-systems.com>.
Serge Knystautas wrote:
> I would very much like $foo where foo is null to evaluate to "". If
> it's a toggle to address backwards compatibility, great... I just care
> that I can do it. :)
is that what it does now?
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Nathan Bubna <na...@esha.com>.
Serge Knystautas said:
> Nathan Bubna wrote:
> > hey, no thread polluting/hijacking! :)
>
> Sorry Nathan, I didn't appreciate the difference between setting and
> rendering and just notices null context attributes.
hey, no apology needed at all. i know the two issues are similar. i was just
trying to keep the matter clear, not trying to criticize. thus i put the :)
above and the long explanation below. sometimes i wish email was better at
conveying tone. any chance you could get write some special protocol or
whatnot into James for that? i'd use that for everything! ;)
> > seriously, this is a separate issue (reference rendering as opposed to
> > reference setting) and one that has much less support (at least at the
> > moment), and it has a prescribed solution already: just do $!foo all the
> > time. if that's not reasonable to you, then feel free to bring it up in
> > another thread, just don't confuse the issue at hand please. in my
> > experience, that seriously lowers the chances of any consensus being
achieved
> > or any action taken.
>
> I understand, and Geir gave me the workaround already.
yeah, it's good to have him around again, eh? :)
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Serge Knystautas <se...@lokitech.com>.
Nathan Bubna wrote:
> hey, no thread polluting/hijacking! :)
Sorry Nathan, I didn't appreciate the difference between setting and
rendering and just notices null context attributes.
> seriously, this is a separate issue (reference rendering as opposed to
> reference setting) and one that has much less support (at least at the
> moment), and it has a prescribed solution already: just do $!foo all the
> time. if that's not reasonable to you, then feel free to bring it up in
> another thread, just don't confuse the issue at hand please. in my
> experience, that seriously lowers the chances of any consensus being achieved
> or any action taken.
I understand, and Geir gave me the workaround already.
--
Serge Knystautas
President
Lokitech >>> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr said:
> On Jan 15, 2004, at 6:47 PM, Nathan Bubna wrote:
> > Serge Knystautas said:
> >> lloyd wrote:
> >>> Nathan Bubna wrote:
> >>>> personally, it might break the hacks i've used to get around this
> >>>> "feature" in
> >>>> the past. that's ok with me, but i don't know about other people.
> >>>>
> >>>> again, i think it'd be best to have a velocity.properties setting
> >>>> that
> >>>> toggles
> >>>> this behavior. just set the default to the old behavior, and then
> >>>> we
> >>>> needn't
> >>>> worry about BC.
> >>>
> >>> ...or just make it the toggle transitional - deprecate it for a
> >>> following release of velocity?
> >>>
> >>> i can't imagine why anyone would want the old (ie current)
> >>> behavior...
> >>
> >> I would very much like $foo where foo is null to evaluate to "". If
> >> it's a toggle to address backwards compatibility, great... I just care
> >> that I can do it. :)
> >
> > hey, no thread polluting/hijacking! :)
> >
> > seriously, this is a separate issue (reference rendering as opposed to
> > reference setting) and one that has much less support (at least at the
> > moment), and it has a prescribed solution already: just do $!foo all
> > the
> > time. if that's not reasonable to you, then feel free to bring it up
> > in
> > another thread, just don't confuse the issue at hand please. in my
> > experience, that seriously lowers the chances of any consensus being
> > achieved
> > or any action taken.
>
> Oh, pipe down :)
yeah, yeah, i hear you. :)
> I think there's 100% consensus on this one, and my fears of breakage
> are solved w/ the switch that will go away in 2.0...
>
> There are actually two solutions - one is $!foo, and the other is the
> handler...
oh yeah, that's even better.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Jan 15, 2004, at 6:47 PM, Nathan Bubna wrote:
> Serge Knystautas said:
>> lloyd wrote:
>>> Nathan Bubna wrote:
>>>> personally, it might break the hacks i've used to get around this
>>>> "feature" in
>>>> the past. that's ok with me, but i don't know about other people.
>>>>
>>>> again, i think it'd be best to have a velocity.properties setting
>>>> that
>>>> toggles
>>>> this behavior. just set the default to the old behavior, and then
>>>> we
>>>> needn't
>>>> worry about BC.
>>>
>>> ...or just make it the toggle transitional - deprecate it for a
>>> following release of velocity?
>>>
>>> i can't imagine why anyone would want the old (ie current)
>>> behavior...
>>
>> I would very much like $foo where foo is null to evaluate to "". If
>> it's a toggle to address backwards compatibility, great... I just care
>> that I can do it. :)
>
> hey, no thread polluting/hijacking! :)
>
> seriously, this is a separate issue (reference rendering as opposed to
> reference setting) and one that has much less support (at least at the
> moment), and it has a prescribed solution already: just do $!foo all
> the
> time. if that's not reasonable to you, then feel free to bring it up
> in
> another thread, just don't confuse the issue at hand please. in my
> experience, that seriously lowers the chances of any consensus being
> achieved
> or any action taken.
Oh, pipe down :)
I think there's 100% consensus on this one, and my fears of breakage
are solved w/ the switch that will go away in 2.0...
There are actually two solutions - one is $!foo, and the other is the
handler...
>
> Nathan Bubna
> nathan@esha.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Nathan Bubna <na...@esha.com>.
Serge Knystautas said:
> lloyd wrote:
> > Nathan Bubna wrote:
> >> personally, it might break the hacks i've used to get around this
> >> "feature" in
> >> the past. that's ok with me, but i don't know about other people.
> >>
> >> again, i think it'd be best to have a velocity.properties setting that
> >> toggles
> >> this behavior. just set the default to the old behavior, and then we
> >> needn't
> >> worry about BC.
> >
> > ...or just make it the toggle transitional - deprecate it for a
> > following release of velocity?
> >
> > i can't imagine why anyone would want the old (ie current) behavior...
>
> I would very much like $foo where foo is null to evaluate to "". If
> it's a toggle to address backwards compatibility, great... I just care
> that I can do it. :)
hey, no thread polluting/hijacking! :)
seriously, this is a separate issue (reference rendering as opposed to
reference setting) and one that has much less support (at least at the
moment), and it has a prescribed solution already: just do $!foo all the
time. if that's not reasonable to you, then feel free to bring it up in
another thread, just don't confuse the issue at hand please. in my
experience, that seriously lowers the chances of any consensus being achieved
or any action taken.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Jan 15, 2004, at 6:35 PM, Serge Knystautas wrote:
> lloyd wrote:
>> Nathan Bubna wrote:
>>> personally, it might break the hacks i've used to get around this
>>> "feature" in
>>> the past. that's ok with me, but i don't know about other people.
>>>
>>> again, i think it'd be best to have a velocity.properties setting
>>> that toggles
>>> this behavior. just set the default to the old behavior, and then
>>> we needn't
>>> worry about BC.
>> ...or just make it the toggle transitional - deprecate it for a
>> following release of velocity?
>> i can't imagine why anyone would want the old (ie current) behavior...
>
> I would very much like $foo where foo is null to evaluate to "". If
> it's a toggle to address backwards compatibility, great... I just care
> that I can do it. :)
rather than "$foo"? you can do that with an event handler...
geir
>
> --
> Serge Knystautas
> President
> Lokitech >>> software . strategy . design >> http://www.lokitech.com
> p. 301.656.5501
> e. sergek@lokitech.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Serge Knystautas <se...@lokitech.com>.
lloyd wrote:
> Nathan Bubna wrote:
>> personally, it might break the hacks i've used to get around this
>> "feature" in
>> the past. that's ok with me, but i don't know about other people.
>>
>> again, i think it'd be best to have a velocity.properties setting that
>> toggles
>> this behavior. just set the default to the old behavior, and then we
>> needn't
>> worry about BC.
>
> ...or just make it the toggle transitional - deprecate it for a
> following release of velocity?
>
> i can't imagine why anyone would want the old (ie current) behavior...
I would very much like $foo where foo is null to evaluate to "". If
it's a toggle to address backwards compatibility, great... I just care
that I can do it. :)
--
Serge Knystautas
President
Lokitech >>> software . strategy . design >> http://www.lokitech.com
p. 301.656.5501
e. sergek@lokitech.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Terry Steichen <te...@net-frame.com>.
+1
Regards,
Terry
----- Original Message -----
From: "Geir Magnusson Jr" <ge...@4quarters.com>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: Friday, January 16, 2004 7:59 AM
Subject: Re: POLL: null context attribute values
>
> On Jan 16, 2004, at 7:15 AM, Christoph.Reck@dlr.de wrote:
>
> > Geir Magnusson Jr wrote:
> >> On Jan 15, 2004, at 6:38 PM, Nathan Bubna wrote:
> >>> lloyd said:
> >>>
> >>>> Nathan Bubna wrote:
> >> [snip]
> >>>> ...or just make it the toggle transitional - deprecate it for a
> >>>> following release of velocity?
> >>>
> >>>
> >>> sure, i'd suggest we could remove the toggle in the next release
> >>> where we put
> >>> aside BC concerns. 2.0 or whatever.
> >>>
> >>>> i can't imagine why anyone would want the old (ie current)
> >>>> behavior...
> >>>
> >>> well, then i've just barely got you beat there,
> >>> because i can imagine precisely one: backwards compatibility! ;)
> >>>
> >> I still wish I could recall the reason, because we had one.... :)
> >
> > The reason was due to the fact that a Hashtable does not accept nulls,
> > but Velocity uses a Map. Geir wanted the original vel implementation
> > to allow backing the context by whatever the application developers
> > desire - even a Hashtable.
>
> Thank you! That's amazing that you can remember that.
>
> >
> >
> > Now the proper BC proceeding should be:
> >
> > 1) The next relase of velocity sould have a new switch that defaults to
> > the old form if not explicetely set in the properties. A loud WARNING
> > should be emitted into the logs (for whoever reads them) that tells
> > to switch it to the new mode after upgrading/verifying any existing
> > templates.
> >
> > 2) Then the release after that can default to the switch the "Right
> > Way" (tm)
> > and emit a WARNING if the switch has not explicetely set in the
> > properties.
> >
>
> That's not a bad plan. Different than what I thought yesterday, but
> that would work. We could do a release w/ the old way as default, w/
> new way as switch to get the map, etc out there. Then immediately
> uprev by 0.1 and have the new way as default, no other difference. And
> then
>
> > 3) In velocity 2.0 the switch can be dropped altogether (or an ERROR
> > can
> > show if it still exits and is set to the old BC mode).
> >
> > For whatever these 0.02c are worth.
>
> In euro, not as much as it used to ... :)
>
> > :) Christoph Reck
> >
> > ---
> > The devil is wise because he is *old* and not because he is *the*
> > devil.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> >
> >
> --
> Geir Magnusson Jr 203-247-1713(m)
> geir@4quarters.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Context scope macros
Posted by Kok Hoor <ko...@solutionx.com.my>.
Hi all,
My company is planning to use Velocity for our new Web Hosting
Service.
I am trying to use the same Velocity instance for all the webapps we
host.
However, it is definitely not desireable for these webapps to share the
same
macros. For example, we might have a site_name VM, but each site might
be
able to override this macro. One problem is that, if I set
velocimacro.permissions.allow.inline.local.scope = true,
And if I place all my macros for a webapp in a special file, say
'macros.vm',
I am not able to invoke them, even after using #parse 'macros.vm'.
Is there any way to do it? Has anybody thought of using Context scope
macros?
Any implementation?
Thanks in advance.
Regards,
Kok Hoor
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: Escaping single quote or double quote (' or '')
Posted by Mike Kienenberger <mk...@alaska.net>.
Kok Hoor <ko...@solutionx.com.my> wrote:
> Hi all,
>
> I am quite new to velocity, and I think what I am asking here is not
> in
> The documents.
>
> Is it possible to escape a single quote (') inside a single quoted
> Expression, like this:
>
> 'test\''
>
> Or
>
> "test\""
>
I've used the following:
#set( $dollarSign = '$' )
#set( $poundSign = '#' )
#set( $doubleQuote = '"' )
I would imagine that you can also do the following although I've never
tested it.
#set( $singleQuote = "'" )
In your example, it'd come out as
"test${singleQuote}"
or
"test${doubleQuote}"
There is no \ notation for velocity (although the docs incorrectly stated
that there was such a thing at one point).
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Escaping single quote or double quote (' or '')
Posted by Kok Hoor <ko...@solutionx.com.my>.
Hi all,
I am quite new to velocity, and I think what I am asking here is not
in
The documents.
Is it possible to escape a single quote (') inside a single quoted
Expression, like this:
'test\''
Or
"test\""
Thanks in advance.
Regards,
Kok Hoor
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Jan 18, 2004, at 4:08 PM, Claude Brisson wrote:
> +1 also
>
> Note that if I understand correctly, the change will not concern only
> method
> calls but all RHSs of the set directive.
> So there is no real need (other than avoiding a warning) for a "null"
> keyword, koz if $null if not in the context, you can write :
>
> #set($foo = $null)
>
> to nullify $foo (i.e. remove it from the context).
Yes.
>
> CloD
>
> ----- Original Message -----
> From: "Barbara Baughman" <ba...@utdallas.edu>
> To: "Velocity Users List" <ve...@jakarta.apache.org>
> Sent: Friday, January 16, 2004 9:44 PM
> Subject: RE: POLL: null context attribute values
>
>
>> +1.
>>
>> I've got my own workarounds for the null behavior, but I'd much rather
>> have it work right. I have been bit by the unusual null behavior.
>>
>> Barbara Baughman
>> X2157
>>
>> On Fri, 16 Jan 2004, Tim Colson wrote:
>>
>>> Peter summarized:
>>>> "a", "b", null, "c" and iterate over it like:
>>>> #foreach ($value in $mylist) $value #end
>>>> will CURRENTLY print: a b b c
>>>> and will THEN print : a b $value c
>>>> The latter one feels correct for almost everyone.
>>>> +1 for the switch and for setting it to the new behavior
>>>> sooner than later.
>>>
>>> +1
>>>
>>> -Timo
>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>>> For additional commands, e-mail:
>>> velocity-user-help@jakarta.apache.org
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
>> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Claude Brisson <cl...@savoirweb.com>.
+1 also
Note that if I understand correctly, the change will not concern only method
calls but all RHSs of the set directive.
So there is no real need (other than avoiding a warning) for a "null"
keyword, koz if $null if not in the context, you can write :
#set($foo = $null)
to nullify $foo (i.e. remove it from the context).
CloD
----- Original Message -----
From: "Barbara Baughman" <ba...@utdallas.edu>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: Friday, January 16, 2004 9:44 PM
Subject: RE: POLL: null context attribute values
> +1.
>
> I've got my own workarounds for the null behavior, but I'd much rather
> have it work right. I have been bit by the unusual null behavior.
>
> Barbara Baughman
> X2157
>
> On Fri, 16 Jan 2004, Tim Colson wrote:
>
> > Peter summarized:
> > > "a", "b", null, "c" and iterate over it like:
> > > #foreach ($value in $mylist) $value #end
> > > will CURRENTLY print: a b b c
> > > and will THEN print : a b $value c
> > > The latter one feels correct for almost everyone.
> > > +1 for the switch and for setting it to the new behavior
> > > sooner than later.
> >
> > +1
> >
> > -Timo
> >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: POLL: null context attribute values
Posted by Barbara Baughman <ba...@utdallas.edu>.
+1.
I've got my own workarounds for the null behavior, but I'd much rather
have it work right. I have been bit by the unusual null behavior.
Barbara Baughman
X2157
On Fri, 16 Jan 2004, Tim Colson wrote:
> Peter summarized:
> > "a", "b", null, "c" and iterate over it like:
> > #foreach ($value in $mylist) $value #end
> > will CURRENTLY print: a b b c
> > and will THEN print : a b $value c
> > The latter one feels correct for almost everyone.
> > +1 for the switch and for setting it to the new behavior
> > sooner than later.
>
> +1
>
> -Timo
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
RE: POLL: null context attribute values
Posted by Tim Colson <tc...@cisco.com>.
Peter summarized:
> "a", "b", null, "c" and iterate over it like:
> #foreach ($value in $mylist) $value #end
> will CURRENTLY print: a b b c
> and will THEN print : a b $value c
> The latter one feels correct for almost everyone.
> +1 for the switch and for setting it to the new behavior
> sooner than later.
+1
-Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Peter Romianowski <an...@gmx.de>.
> Thanks Nathan for clearing that up. But now after Claude's email I'm
> confused again.
>
> Is there a difference between
>
> #if ($foo == null)
>
> and #if ($foo) ?
>
> The reason I ask is that many of my reference properties are database
> fields, which may be null. I check for null with:
> if($record.fieldname) field is not defined #end
> if(!$record.fieldname) field is defined #end
>
> In both cases, $record is defined, but the property fieldname may or may not
> be null.
If I follow this thread correctly, then only the possibility to actually
SET a reference to NULL is the point.
So your VTL will still be the same. But if you have a list like this:
"a", "b", null, "c"
and iterate over it like:
#foreach ($value in $mylist) $value #end
will CURRENTLY print: a b b c
and will THEN print : a b $value c
The latter one feels correct for almost everyone. Nathan's example is
quite the same.
+1 for the switch and for setting it to the new behavior sooner than later.
Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Will Glass-Husain <wg...@forio.com>.
Makes sense to me, thanks. next time I'll pay better attention :-)
WILL
----- Original Message -----
From: "Nathan Bubna" <na...@esha.com>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: Friday, January 16, 2004 9:25 AM
Subject: Re: POLL: null context attribute values
> Will Glass-Husain said:
> > Thanks Nathan for clearing that up. But now after Claude's email I'm
> > confused again.
> >
> > Is there a difference between
> >
> > #if ($foo == null)
> >
> > and #if ($foo) ?
>
> yes, for two reasons:
>
> - the first is invalid syntax. Velocity has no "null" keyword (yet). :)
>
> - #if( $foo ) is equivalent to if( foo != null && foo != Boolean.FALSE )
in
> java.
>
> > The reason I ask is that many of my reference properties are database
> > fields, which may be null. I check for null with:
> > if($record.fieldname) field is not defined #end
> > if(!$record.fieldname) field is defined #end
> >
> > In both cases, $record is defined, but the property fieldname may or may
not
> > be null.
> >
> > Will this still be the same with the new proposal?
>
> yes, this proposal will not change that. it will change nothing in how
#if()
> itself behaves. it only changes the behavior of #set() when the RHS
evaluates
> to null and #foreach() when the list/map/iterator/array contains null
values.
>
> Claude Brisson said:
> > > hum.... quite...
> > >
> > > #if( $foo )
> > > $foo
> > > #elseif ($foo == false)
> > > foo is false
> > > #else
> > > foo is null
> > > #end
> > >
> > > :-)
> > >
> > > CloD
> > >
> > > ----- Original Message -----
> > > From: "Nathan Bubna" <na...@esha.com>
> > > To: "Velocity Users List" <ve...@jakarta.apache.org>
> > > Sent: Friday, January 16, 2004 5:47 PM
> > > Subject: Re: POLL: null context attribute values
> > >
> > >
> > > > Will Glass-Husain said:
> > > > > Question: Would the following syntax still work?
> > > > >
> > > > > #if($reference)
> > > > > $reference is defined
> > > > > #end
> > > >
> > > > yes. in fact, it should work even better since:
> > > >
> > > > #foreach( $foo in $foos )
> > > > #if( $foo ) $foo #else foo is null #end
> > > > #end
> > > >
> > > > should now work as intuition expects when $foos contains null
values,
> > and
> > > >
> > > > #set( $foo = "bar" )
> > > > #set( $foo = $tool.returnNull() )
> > > > #if( $foo ) $foo #else foo is null #end
> > > >
> > > > should display " foo is null " instead of " bar " (as it does
> > currently).
> > > >
> > > > make sense now?
> > > >
> > > > Nathan Bubna
> > > > nathan@esha.com
> > > >
> > > >
> > > > Geir Magnusson Jr said:
> > > > > > On Jan 16, 2004, at 7:15 AM, Christoph.Reck@dlr.de wrote:
> > > > > >
> > > > > > > Geir Magnusson Jr wrote:
> > > > > > >> On Jan 15, 2004, at 6:38 PM, Nathan Bubna wrote:
> > > > > > >>> lloyd said:
> > > > > > >>>
> > > > > > >>>> Nathan Bubna wrote:
> > > > > > >> [snip]
> > > > > > >>>> ...or just make it the toggle transitional - deprecate it
for a
> > > > > > >>>> following release of velocity?
> > > > > > >>>
> > > > > > >>>
> > > > > > >>> sure, i'd suggest we could remove the toggle in the next
release
> > > > > > >>> where we put
> > > > > > >>> aside BC concerns. 2.0 or whatever.
> > > > > > >>>
> > > > > > >>>> i can't imagine why anyone would want the old (ie current)
> > > > > > >>>> behavior...
> > > > > > >>>
> > > > > > >>> well, then i've just barely got you beat there,
> > > > > > >>> because i can imagine precisely one: backwards
compatibility!
> > ;)
> > > > > > >>>
> > > > > > >> I still wish I could recall the reason, because we had
one.... :)
> > > > > > >
> > > > > > > The reason was due to the fact that a Hashtable does not
accept
> > > nulls,
> > > > > > > but Velocity uses a Map. Geir wanted the original vel
> > implementation
> > > > > > > to allow backing the context by whatever the application
> > developers
> > > > > > > desire - even a Hashtable.
> > > > > >
> > > > > > Thank you! That's amazing that you can remember that.
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Now the proper BC proceeding should be:
> > > > > > >
> > > > > > > 1) The next relase of velocity sould have a new switch that
> > defaults
> > > to
> > > > > > > the old form if not explicetely set in the properties. A loud
> > > WARNING
> > > > > > > should be emitted into the logs (for whoever reads them) that
> > tells
> > > > > > > to switch it to the new mode after upgrading/verifying any
> > existing
> > > > > > > templates.
> > > > > > >
> > > > > > > 2) Then the release after that can default to the switch the
> > "Right
> > > > > > > Way" (tm)
> > > > > > > and emit a WARNING if the switch has not explicetely set in
the
> > > > > > > properties.
> > > > > > >
> > > > > >
> > > > > > That's not a bad plan. Different than what I thought yesterday,
but
> > > > > > that would work. We could do a release w/ the old way as
default,
> > w/
> > > > > > new way as switch to get the map, etc out there. Then
immediately
> > > > > > uprev by 0.1 and have the new way as default, no other
difference.
> > And
> > > > > > then
> > > > > >
> > > > > > > 3) In velocity 2.0 the switch can be dropped altogether (or an
> > ERROR
> > > > > > > can
> > > > > > > show if it still exits and is set to the old BC mode).
> > > > > > >
> > > > > > > For whatever these 0.02c are worth.
> > > > > >
> > > > > > In euro, not as much as it used to ... :)
> > > > > >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Nathan Bubna <na...@esha.com>.
Will Glass-Husain said:
> Thanks Nathan for clearing that up. But now after Claude's email I'm
> confused again.
>
> Is there a difference between
>
> #if ($foo == null)
>
> and #if ($foo) ?
yes, for two reasons:
- the first is invalid syntax. Velocity has no "null" keyword (yet). :)
- #if( $foo ) is equivalent to if( foo != null && foo != Boolean.FALSE ) in
java.
> The reason I ask is that many of my reference properties are database
> fields, which may be null. I check for null with:
> if($record.fieldname) field is not defined #end
> if(!$record.fieldname) field is defined #end
>
> In both cases, $record is defined, but the property fieldname may or may not
> be null.
>
> Will this still be the same with the new proposal?
yes, this proposal will not change that. it will change nothing in how #if()
itself behaves. it only changes the behavior of #set() when the RHS evaluates
to null and #foreach() when the list/map/iterator/array contains null values.
Claude Brisson said:
> > hum.... quite...
> >
> > #if( $foo )
> > $foo
> > #elseif ($foo == false)
> > foo is false
> > #else
> > foo is null
> > #end
> >
> > :-)
> >
> > CloD
> >
> > ----- Original Message -----
> > From: "Nathan Bubna" <na...@esha.com>
> > To: "Velocity Users List" <ve...@jakarta.apache.org>
> > Sent: Friday, January 16, 2004 5:47 PM
> > Subject: Re: POLL: null context attribute values
> >
> >
> > > Will Glass-Husain said:
> > > > Question: Would the following syntax still work?
> > > >
> > > > #if($reference)
> > > > $reference is defined
> > > > #end
> > >
> > > yes. in fact, it should work even better since:
> > >
> > > #foreach( $foo in $foos )
> > > #if( $foo ) $foo #else foo is null #end
> > > #end
> > >
> > > should now work as intuition expects when $foos contains null values,
> and
> > >
> > > #set( $foo = "bar" )
> > > #set( $foo = $tool.returnNull() )
> > > #if( $foo ) $foo #else foo is null #end
> > >
> > > should display " foo is null " instead of " bar " (as it does
> currently).
> > >
> > > make sense now?
> > >
> > > Nathan Bubna
> > > nathan@esha.com
> > >
> > >
> > > Geir Magnusson Jr said:
> > > > > On Jan 16, 2004, at 7:15 AM, Christoph.Reck@dlr.de wrote:
> > > > >
> > > > > > Geir Magnusson Jr wrote:
> > > > > >> On Jan 15, 2004, at 6:38 PM, Nathan Bubna wrote:
> > > > > >>> lloyd said:
> > > > > >>>
> > > > > >>>> Nathan Bubna wrote:
> > > > > >> [snip]
> > > > > >>>> ...or just make it the toggle transitional - deprecate it for a
> > > > > >>>> following release of velocity?
> > > > > >>>
> > > > > >>>
> > > > > >>> sure, i'd suggest we could remove the toggle in the next release
> > > > > >>> where we put
> > > > > >>> aside BC concerns. 2.0 or whatever.
> > > > > >>>
> > > > > >>>> i can't imagine why anyone would want the old (ie current)
> > > > > >>>> behavior...
> > > > > >>>
> > > > > >>> well, then i've just barely got you beat there,
> > > > > >>> because i can imagine precisely one: backwards compatibility!
> ;)
> > > > > >>>
> > > > > >> I still wish I could recall the reason, because we had one.... :)
> > > > > >
> > > > > > The reason was due to the fact that a Hashtable does not accept
> > nulls,
> > > > > > but Velocity uses a Map. Geir wanted the original vel
> implementation
> > > > > > to allow backing the context by whatever the application
> developers
> > > > > > desire - even a Hashtable.
> > > > >
> > > > > Thank you! That's amazing that you can remember that.
> > > > >
> > > > > >
> > > > > >
> > > > > > Now the proper BC proceeding should be:
> > > > > >
> > > > > > 1) The next relase of velocity sould have a new switch that
> defaults
> > to
> > > > > > the old form if not explicetely set in the properties. A loud
> > WARNING
> > > > > > should be emitted into the logs (for whoever reads them) that
> tells
> > > > > > to switch it to the new mode after upgrading/verifying any
> existing
> > > > > > templates.
> > > > > >
> > > > > > 2) Then the release after that can default to the switch the
> "Right
> > > > > > Way" (tm)
> > > > > > and emit a WARNING if the switch has not explicetely set in the
> > > > > > properties.
> > > > > >
> > > > >
> > > > > That's not a bad plan. Different than what I thought yesterday, but
> > > > > that would work. We could do a release w/ the old way as default,
> w/
> > > > > new way as switch to get the map, etc out there. Then immediately
> > > > > uprev by 0.1 and have the new way as default, no other difference.
> And
> > > > > then
> > > > >
> > > > > > 3) In velocity 2.0 the switch can be dropped altogether (or an
> ERROR
> > > > > > can
> > > > > > show if it still exits and is set to the old BC mode).
> > > > > >
> > > > > > For whatever these 0.02c are worth.
> > > > >
> > > > > In euro, not as much as it used to ... :)
> > > > >
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Will Glass-Husain <wg...@forio.com>.
Thanks Nathan for clearing that up. But now after Claude's email I'm
confused again.
Is there a difference between
#if ($foo == null)
and #if ($foo) ?
The reason I ask is that many of my reference properties are database
fields, which may be null. I check for null with:
if($record.fieldname) field is not defined #end
if(!$record.fieldname) field is defined #end
In both cases, $record is defined, but the property fieldname may or may not
be null.
Will this still be the same with the new proposal?
WILL
----- Original Message -----
From: "Claude Brisson" <cl...@savoirweb.com>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: Friday, January 16, 2004 8:55 AM
Subject: Re: POLL: null context attribute values
> hum.... quite...
>
> #if( $foo )
> $foo
> #elseif ($foo == false)
> foo is false
> #else
> foo is null
> #end
>
> :-)
>
> CloD
>
> ----- Original Message -----
> From: "Nathan Bubna" <na...@esha.com>
> To: "Velocity Users List" <ve...@jakarta.apache.org>
> Sent: Friday, January 16, 2004 5:47 PM
> Subject: Re: POLL: null context attribute values
>
>
> > Will Glass-Husain said:
> > > Question: Would the following syntax still work?
> > >
> > > #if($reference)
> > > $reference is defined
> > > #end
> >
> > yes. in fact, it should work even better since:
> >
> > #foreach( $foo in $foos )
> > #if( $foo ) $foo #else foo is null #end
> > #end
> >
> > should now work as intuition expects when $foos contains null values,
and
> >
> > #set( $foo = "bar" )
> > #set( $foo = $tool.returnNull() )
> > #if( $foo ) $foo #else foo is null #end
> >
> > should display " foo is null " instead of " bar " (as it does
currently).
> >
> > make sense now?
> >
> > Nathan Bubna
> > nathan@esha.com
> >
> >
> > Geir Magnusson Jr said:
> > > > On Jan 16, 2004, at 7:15 AM, Christoph.Reck@dlr.de wrote:
> > > >
> > > > > Geir Magnusson Jr wrote:
> > > > >> On Jan 15, 2004, at 6:38 PM, Nathan Bubna wrote:
> > > > >>> lloyd said:
> > > > >>>
> > > > >>>> Nathan Bubna wrote:
> > > > >> [snip]
> > > > >>>> ...or just make it the toggle transitional - deprecate it for a
> > > > >>>> following release of velocity?
> > > > >>>
> > > > >>>
> > > > >>> sure, i'd suggest we could remove the toggle in the next release
> > > > >>> where we put
> > > > >>> aside BC concerns. 2.0 or whatever.
> > > > >>>
> > > > >>>> i can't imagine why anyone would want the old (ie current)
> > > > >>>> behavior...
> > > > >>>
> > > > >>> well, then i've just barely got you beat there,
> > > > >>> because i can imagine precisely one: backwards compatibility!
;)
> > > > >>>
> > > > >> I still wish I could recall the reason, because we had one.... :)
> > > > >
> > > > > The reason was due to the fact that a Hashtable does not accept
> nulls,
> > > > > but Velocity uses a Map. Geir wanted the original vel
implementation
> > > > > to allow backing the context by whatever the application
developers
> > > > > desire - even a Hashtable.
> > > >
> > > > Thank you! That's amazing that you can remember that.
> > > >
> > > > >
> > > > >
> > > > > Now the proper BC proceeding should be:
> > > > >
> > > > > 1) The next relase of velocity sould have a new switch that
defaults
> to
> > > > > the old form if not explicetely set in the properties. A loud
> WARNING
> > > > > should be emitted into the logs (for whoever reads them) that
tells
> > > > > to switch it to the new mode after upgrading/verifying any
existing
> > > > > templates.
> > > > >
> > > > > 2) Then the release after that can default to the switch the
"Right
> > > > > Way" (tm)
> > > > > and emit a WARNING if the switch has not explicetely set in the
> > > > > properties.
> > > > >
> > > >
> > > > That's not a bad plan. Different than what I thought yesterday, but
> > > > that would work. We could do a release w/ the old way as default,
w/
> > > > new way as switch to get the map, etc out there. Then immediately
> > > > uprev by 0.1 and have the new way as default, no other difference.
And
> > > > then
> > > >
> > > > > 3) In velocity 2.0 the switch can be dropped altogether (or an
ERROR
> > > > > can
> > > > > show if it still exits and is set to the old BC mode).
> > > > >
> > > > > For whatever these 0.02c are worth.
> > > >
> > > > In euro, not as much as it used to ... :)
> > > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Claude Brisson <cl...@savoirweb.com>.
hum.... quite...
#if( $foo )
$foo
#elseif ($foo == false)
foo is false
#else
foo is null
#end
:-)
CloD
----- Original Message -----
From: "Nathan Bubna" <na...@esha.com>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: Friday, January 16, 2004 5:47 PM
Subject: Re: POLL: null context attribute values
> Will Glass-Husain said:
> > Question: Would the following syntax still work?
> >
> > #if($reference)
> > $reference is defined
> > #end
>
> yes. in fact, it should work even better since:
>
> #foreach( $foo in $foos )
> #if( $foo ) $foo #else foo is null #end
> #end
>
> should now work as intuition expects when $foos contains null values, and
>
> #set( $foo = "bar" )
> #set( $foo = $tool.returnNull() )
> #if( $foo ) $foo #else foo is null #end
>
> should display " foo is null " instead of " bar " (as it does currently).
>
> make sense now?
>
> Nathan Bubna
> nathan@esha.com
>
>
> Geir Magnusson Jr said:
> > > On Jan 16, 2004, at 7:15 AM, Christoph.Reck@dlr.de wrote:
> > >
> > > > Geir Magnusson Jr wrote:
> > > >> On Jan 15, 2004, at 6:38 PM, Nathan Bubna wrote:
> > > >>> lloyd said:
> > > >>>
> > > >>>> Nathan Bubna wrote:
> > > >> [snip]
> > > >>>> ...or just make it the toggle transitional - deprecate it for a
> > > >>>> following release of velocity?
> > > >>>
> > > >>>
> > > >>> sure, i'd suggest we could remove the toggle in the next release
> > > >>> where we put
> > > >>> aside BC concerns. 2.0 or whatever.
> > > >>>
> > > >>>> i can't imagine why anyone would want the old (ie current)
> > > >>>> behavior...
> > > >>>
> > > >>> well, then i've just barely got you beat there,
> > > >>> because i can imagine precisely one: backwards compatibility! ;)
> > > >>>
> > > >> I still wish I could recall the reason, because we had one.... :)
> > > >
> > > > The reason was due to the fact that a Hashtable does not accept
nulls,
> > > > but Velocity uses a Map. Geir wanted the original vel implementation
> > > > to allow backing the context by whatever the application developers
> > > > desire - even a Hashtable.
> > >
> > > Thank you! That's amazing that you can remember that.
> > >
> > > >
> > > >
> > > > Now the proper BC proceeding should be:
> > > >
> > > > 1) The next relase of velocity sould have a new switch that defaults
to
> > > > the old form if not explicetely set in the properties. A loud
WARNING
> > > > should be emitted into the logs (for whoever reads them) that tells
> > > > to switch it to the new mode after upgrading/verifying any existing
> > > > templates.
> > > >
> > > > 2) Then the release after that can default to the switch the "Right
> > > > Way" (tm)
> > > > and emit a WARNING if the switch has not explicetely set in the
> > > > properties.
> > > >
> > >
> > > That's not a bad plan. Different than what I thought yesterday, but
> > > that would work. We could do a release w/ the old way as default, w/
> > > new way as switch to get the map, etc out there. Then immediately
> > > uprev by 0.1 and have the new way as default, no other difference. And
> > > then
> > >
> > > > 3) In velocity 2.0 the switch can be dropped altogether (or an ERROR
> > > > can
> > > > show if it still exits and is set to the old BC mode).
> > > >
> > > > For whatever these 0.02c are worth.
> > >
> > > In euro, not as much as it used to ... :)
> > >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Nathan Bubna <na...@esha.com>.
Will Glass-Husain said:
> Question: Would the following syntax still work?
>
> #if($reference)
> $reference is defined
> #end
yes. in fact, it should work even better since:
#foreach( $foo in $foos )
#if( $foo ) $foo #else foo is null #end
#end
should now work as intuition expects when $foos contains null values, and
#set( $foo = "bar" )
#set( $foo = $tool.returnNull() )
#if( $foo ) $foo #else foo is null #end
should display " foo is null " instead of " bar " (as it does currently).
make sense now?
Nathan Bubna
nathan@esha.com
Geir Magnusson Jr said:
> > On Jan 16, 2004, at 7:15 AM, Christoph.Reck@dlr.de wrote:
> >
> > > Geir Magnusson Jr wrote:
> > >> On Jan 15, 2004, at 6:38 PM, Nathan Bubna wrote:
> > >>> lloyd said:
> > >>>
> > >>>> Nathan Bubna wrote:
> > >> [snip]
> > >>>> ...or just make it the toggle transitional - deprecate it for a
> > >>>> following release of velocity?
> > >>>
> > >>>
> > >>> sure, i'd suggest we could remove the toggle in the next release
> > >>> where we put
> > >>> aside BC concerns. 2.0 or whatever.
> > >>>
> > >>>> i can't imagine why anyone would want the old (ie current)
> > >>>> behavior...
> > >>>
> > >>> well, then i've just barely got you beat there,
> > >>> because i can imagine precisely one: backwards compatibility! ;)
> > >>>
> > >> I still wish I could recall the reason, because we had one.... :)
> > >
> > > The reason was due to the fact that a Hashtable does not accept nulls,
> > > but Velocity uses a Map. Geir wanted the original vel implementation
> > > to allow backing the context by whatever the application developers
> > > desire - even a Hashtable.
> >
> > Thank you! That's amazing that you can remember that.
> >
> > >
> > >
> > > Now the proper BC proceeding should be:
> > >
> > > 1) The next relase of velocity sould have a new switch that defaults to
> > > the old form if not explicetely set in the properties. A loud WARNING
> > > should be emitted into the logs (for whoever reads them) that tells
> > > to switch it to the new mode after upgrading/verifying any existing
> > > templates.
> > >
> > > 2) Then the release after that can default to the switch the "Right
> > > Way" (tm)
> > > and emit a WARNING if the switch has not explicetely set in the
> > > properties.
> > >
> >
> > That's not a bad plan. Different than what I thought yesterday, but
> > that would work. We could do a release w/ the old way as default, w/
> > new way as switch to get the map, etc out there. Then immediately
> > uprev by 0.1 and have the new way as default, no other difference. And
> > then
> >
> > > 3) In velocity 2.0 the switch can be dropped altogether (or an ERROR
> > > can
> > > show if it still exits and is set to the old BC mode).
> > >
> > > For whatever these 0.02c are worth.
> >
> > In euro, not as much as it used to ... :)
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Will Glass-Husain <wg...@forio.com>.
Question: Would the following syntax still work?
#if($reference)
$reference is defined
#end
??
WILL
----- Original Message -----
From: "Geir Magnusson Jr" <ge...@4quarters.com>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: Friday, January 16, 2004 4:59 AM
Subject: Re: POLL: null context attribute values
>
> On Jan 16, 2004, at 7:15 AM, Christoph.Reck@dlr.de wrote:
>
> > Geir Magnusson Jr wrote:
> >> On Jan 15, 2004, at 6:38 PM, Nathan Bubna wrote:
> >>> lloyd said:
> >>>
> >>>> Nathan Bubna wrote:
> >> [snip]
> >>>> ...or just make it the toggle transitional - deprecate it for a
> >>>> following release of velocity?
> >>>
> >>>
> >>> sure, i'd suggest we could remove the toggle in the next release
> >>> where we put
> >>> aside BC concerns. 2.0 or whatever.
> >>>
> >>>> i can't imagine why anyone would want the old (ie current)
> >>>> behavior...
> >>>
> >>> well, then i've just barely got you beat there,
> >>> because i can imagine precisely one: backwards compatibility! ;)
> >>>
> >> I still wish I could recall the reason, because we had one.... :)
> >
> > The reason was due to the fact that a Hashtable does not accept nulls,
> > but Velocity uses a Map. Geir wanted the original vel implementation
> > to allow backing the context by whatever the application developers
> > desire - even a Hashtable.
>
> Thank you! That's amazing that you can remember that.
>
> >
> >
> > Now the proper BC proceeding should be:
> >
> > 1) The next relase of velocity sould have a new switch that defaults to
> > the old form if not explicetely set in the properties. A loud WARNING
> > should be emitted into the logs (for whoever reads them) that tells
> > to switch it to the new mode after upgrading/verifying any existing
> > templates.
> >
> > 2) Then the release after that can default to the switch the "Right
> > Way" (tm)
> > and emit a WARNING if the switch has not explicetely set in the
> > properties.
> >
>
> That's not a bad plan. Different than what I thought yesterday, but
> that would work. We could do a release w/ the old way as default, w/
> new way as switch to get the map, etc out there. Then immediately
> uprev by 0.1 and have the new way as default, no other difference. And
> then
>
> > 3) In velocity 2.0 the switch can be dropped altogether (or an ERROR
> > can
> > show if it still exits and is set to the old BC mode).
> >
> > For whatever these 0.02c are worth.
>
> In euro, not as much as it used to ... :)
>
> > :) Christoph Reck
> >
> > ---
> > The devil is wise because he is *old* and not because he is *the*
> > devil.
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-user-help@jakarta.apache.org
> >
> >
> --
> Geir Magnusson Jr 203-247-1713(m)
> geir@4quarters.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Jan 16, 2004, at 7:15 AM, Christoph.Reck@dlr.de wrote:
> Geir Magnusson Jr wrote:
>> On Jan 15, 2004, at 6:38 PM, Nathan Bubna wrote:
>>> lloyd said:
>>>
>>>> Nathan Bubna wrote:
>> [snip]
>>>> ...or just make it the toggle transitional - deprecate it for a
>>>> following release of velocity?
>>>
>>>
>>> sure, i'd suggest we could remove the toggle in the next release
>>> where we put
>>> aside BC concerns. 2.0 or whatever.
>>>
>>>> i can't imagine why anyone would want the old (ie current)
>>>> behavior...
>>>
>>> well, then i've just barely got you beat there,
>>> because i can imagine precisely one: backwards compatibility! ;)
>>>
>> I still wish I could recall the reason, because we had one.... :)
>
> The reason was due to the fact that a Hashtable does not accept nulls,
> but Velocity uses a Map. Geir wanted the original vel implementation
> to allow backing the context by whatever the application developers
> desire - even a Hashtable.
Thank you! That's amazing that you can remember that.
>
>
> Now the proper BC proceeding should be:
>
> 1) The next relase of velocity sould have a new switch that defaults to
> the old form if not explicetely set in the properties. A loud WARNING
> should be emitted into the logs (for whoever reads them) that tells
> to switch it to the new mode after upgrading/verifying any existing
> templates.
>
> 2) Then the release after that can default to the switch the "Right
> Way" (tm)
> and emit a WARNING if the switch has not explicetely set in the
> properties.
>
That's not a bad plan. Different than what I thought yesterday, but
that would work. We could do a release w/ the old way as default, w/
new way as switch to get the map, etc out there. Then immediately
uprev by 0.1 and have the new way as default, no other difference. And
then
> 3) In velocity 2.0 the switch can be dropped altogether (or an ERROR
> can
> show if it still exits and is set to the old BC mode).
>
> For whatever these 0.02c are worth.
In euro, not as much as it used to ... :)
> :) Christoph Reck
>
> ---
> The devil is wise because he is *old* and not because he is *the*
> devil.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Ch...@dlr.de.
Geir Magnusson Jr wrote:
> On Jan 15, 2004, at 6:38 PM, Nathan Bubna wrote:
>
>> lloyd said:
>>
>>> Nathan Bubna wrote:
>[snip]
>>> ...or just make it the toggle transitional - deprecate it for a
>>> following release of velocity?
>>
>>
>> sure, i'd suggest we could remove the toggle in the next release where
>> we put
>> aside BC concerns. 2.0 or whatever.
>>
>>> i can't imagine why anyone would want the old (ie current) behavior...
>>
>> well, then i've just barely got you beat there,
>> because i can imagine precisely one: backwards compatibility! ;)
>>
>
> I still wish I could recall the reason, because we had one.... :)
The reason was due to the fact that a Hashtable does not accept nulls,
but Velocity uses a Map. Geir wanted the original vel implementation
to allow backing the context by whatever the application developers
desire - even a Hashtable.
Now the proper BC proceeding should be:
1) The next relase of velocity sould have a new switch that defaults to
the old form if not explicetely set in the properties. A loud WARNING
should be emitted into the logs (for whoever reads them) that tells
to switch it to the new mode after upgrading/verifying any existing
templates.
2) Then the release after that can default to the switch the "Right Way" (tm)
and emit a WARNING if the switch has not explicetely set in the properties.
3) In velocity 2.0 the switch can be dropped altogether (or an ERROR can
show if it still exits and is set to the old BC mode).
For whatever these 0.02c are worth.
:) Christoph Reck
---
The devil is wise because he is *old* and not because he is *the* devil.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Jan 15, 2004, at 6:50 PM, Nathan Bubna wrote:
> Geir Magnusson Jr said:
>> On Jan 15, 2004, at 6:38 PM, Nathan Bubna wrote:
>>> lloyd said:
>>>> Nathan Bubna wrote:
>>>>> personally, it might break the hacks i've used to get around this
>>> "feature" in
>>>>> the past. that's ok with me, but i don't know about other people.
>>>>>
>>>>> again, i think it'd be best to have a velocity.properties setting
>>>>> that
>>> toggles
>>>>> this behavior. just set the default to the old behavior, and then
>>>>> we
>>> needn't
>>>>> worry about BC.
>>>>
>>>> ...or just make it the toggle transitional - deprecate it for a
>>>> following release of velocity?
>>>
>>> sure, i'd suggest we could remove the toggle in the next release
>>> where
>>> we put
>>> aside BC concerns. 2.0 or whatever.
>>>
>>>> i can't imagine why anyone would want the old (ie current)
>>>> behavior...
>>>
>>> well, then i've just barely got you beat there,
>>> because i can imagine precisely one: backwards compatibility! ;)
>>>
>>
>> I still wish I could recall the reason, because we had one.... :)
>
> yeah, but obviously it wasn't that important. :)
No doubt. I'm just annoyed at myself for not being able to remember.
I have a mind like a steel sieve...
geir
>
> Nathan Bubna
> nathan@esha.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr said:
> On Jan 15, 2004, at 6:38 PM, Nathan Bubna wrote:
> > lloyd said:
> >> Nathan Bubna wrote:
> >>> personally, it might break the hacks i've used to get around this
> > "feature" in
> >>> the past. that's ok with me, but i don't know about other people.
> >>>
> >>> again, i think it'd be best to have a velocity.properties setting
> >>> that
> > toggles
> >>> this behavior. just set the default to the old behavior, and then we
> > needn't
> >>> worry about BC.
> >>
> >> ...or just make it the toggle transitional - deprecate it for a
> >> following release of velocity?
> >
> > sure, i'd suggest we could remove the toggle in the next release where
> > we put
> > aside BC concerns. 2.0 or whatever.
> >
> >> i can't imagine why anyone would want the old (ie current) behavior...
> >
> > well, then i've just barely got you beat there,
> > because i can imagine precisely one: backwards compatibility! ;)
> >
>
> I still wish I could recall the reason, because we had one.... :)
yeah, but obviously it wasn't that important. :)
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Jan 15, 2004, at 6:38 PM, Nathan Bubna wrote:
> lloyd said:
>> Nathan Bubna wrote:
>>> personally, it might break the hacks i've used to get around this
> "feature" in
>>> the past. that's ok with me, but i don't know about other people.
>>>
>>> again, i think it'd be best to have a velocity.properties setting
>>> that
> toggles
>>> this behavior. just set the default to the old behavior, and then we
> needn't
>>> worry about BC.
>>
>> ...or just make it the toggle transitional - deprecate it for a
>> following release of velocity?
>
> sure, i'd suggest we could remove the toggle in the next release where
> we put
> aside BC concerns. 2.0 or whatever.
>
>> i can't imagine why anyone would want the old (ie current) behavior...
>
> well, then i've just barely got you beat there,
> because i can imagine precisely one: backwards compatibility! ;)
>
I still wish I could recall the reason, because we had one.... :)
geir
> Nathan Bubna
> nathan@esha.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Nathan Bubna <na...@esha.com>.
lloyd said:
> Nathan Bubna wrote:
> > personally, it might break the hacks i've used to get around this
"feature" in
> > the past. that's ok with me, but i don't know about other people.
> >
> > again, i think it'd be best to have a velocity.properties setting that
toggles
> > this behavior. just set the default to the old behavior, and then we
needn't
> > worry about BC.
>
> ...or just make it the toggle transitional - deprecate it for a
> following release of velocity?
sure, i'd suggest we could remove the toggle in the next release where we put
aside BC concerns. 2.0 or whatever.
> i can't imagine why anyone would want the old (ie current) behavior...
well, then i've just barely got you beat there,
because i can imagine precisely one: backwards compatibility! ;)
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by lloyd <su...@twilight-systems.com>.
Nathan Bubna wrote:
> personally, it might break the hacks i've used to get around this "feature" in
> the past. that's ok with me, but i don't know about other people.
>
> again, i think it'd be best to have a velocity.properties setting that toggles
> this behavior. just set the default to the old behavior, and then we needn't
> worry about BC.
...or just make it the toggle transitional - deprecate it for a
following release of velocity?
i can't imagine why anyone would want the old (ie current) behavior...
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Nathan Bubna <na...@esha.com>.
Terry Steichen said:
> Geir said:
> > While it goes against the principle of least surprise, I think we'd
> > make you toggle the new behavior *off* rather than on, so all new users
> > get the new, good behavior...
>
> Please, don't add it so it breaks existing templates. Backward
> compatibility is a development and design principle that's far more
> significant than "least surprise." Myself, I've got literally hundreds of
> templates, some of which are used only occasionally, that such a change may
> cause not to work right.
>
> And there's a real rub with this kind of change, if I understand it right,
> in that you may not know right away that the behavior is changed. I do
> understand the desire to make things work nicely with new templates, but
> there is always the problem of those that invested (perhaps heavily) in the
> "old way." (If the consequences of the change on existing templates is
> really obvious - maybe not the case here - and there's a global way to - at
> least temporarily - revert back to the "old way", maybe that's OK.)
i understand what you are saying, but two thoughts:
first, this doesn't affect older versions of velocity. old templates can
still use old versions if they really need to. second, they won't need to
because this change will come with an on/off switch. if you want the old
behavior, just add one line to your velocity.properties when you change to the
version this change is included in. really, is that such an inconvenience?
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Dave Newton <da...@solaraccess.com>.
On Thu, 2004-01-15 at 23:33, Terry Steichen wrote:
> Please, don't add it so it breaks existing templates. Backward
> compatibility is a development and design principle that's far more
> significant than "least surprise." Myself, I've got literally hundreds of
> templates, some of which are used only occasionally, that such a change may
> cause not to work right.
While I understand your desire to have your templates work, what Geir is
saying makes sense--you should have to switch _off_ the new, more
appropriate behavior to maintain backwards compatability. Old users know
enough to be able to make this change and new users will never have to
know about the weirdness of not dealing with nulls the Right Way (tm)
> (If the consequences of the change on existing templates is
> really obvious - maybe not the case here - and there's a global way to - at
> least temporarily - revert back to the "old way", maybe that's OK.)
Well, #1 he's saying there'd be a switch to do it the Wrong Way (tm) and
#2, I'm sure you have unit tests for all your templates to make sure
they work over code changes... right? ;)
Besides--it's a no-brainer--just don't upgrade until you're ready and/or
willing to deal with the new null behavior.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Jan 15, 2004, at 11:33 PM, Terry Steichen wrote:
> Please, don't add it so it breaks existing templates. Backward
> compatibility is a development and design principle that's far more
> significant than "least surprise." Myself, I've got literally
> hundreds of
> templates, some of which are used only occasionally, that such a
> change may
> cause not to work right.
>
> And there's a real rub with this kind of change, if I understand it
> right,
> in that you may not know right away that the behavior is changed. I do
> understand the desire to make things work nicely with new templates,
> but
> there is always the problem of those that invested (perhaps heavily)
> in the
> "old way." (If the consequences of the change on existing templates is
> really obvious - maybe not the case here - and there's a global way
> to - at
> least temporarily - revert back to the "old way", maybe that's OK.)
That's what we're saying - have a switch that allows you to keep the
old way so you can take advantage of new releases w/o breaking your
compatibility. (Until the 'break with the past' release of "2.0" or
whatever)
geir
>
> Regards,
>
> Terry
>
>> While it goes against the principle of least surprise, I think we'd
>> make you toggle the new behavior *off* rather than on, so all new
>> users
>> get the new, good behavior...
>>
>> geir
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Terry Steichen <te...@net-frame.com>.
Please, don't add it so it breaks existing templates. Backward
compatibility is a development and design principle that's far more
significant than "least surprise." Myself, I've got literally hundreds of
templates, some of which are used only occasionally, that such a change may
cause not to work right.
And there's a real rub with this kind of change, if I understand it right,
in that you may not know right away that the behavior is changed. I do
understand the desire to make things work nicely with new templates, but
there is always the problem of those that invested (perhaps heavily) in the
"old way." (If the consequences of the change on existing templates is
really obvious - maybe not the case here - and there's a global way to - at
least temporarily - revert back to the "old way", maybe that's OK.)
Regards,
Terry
> While it goes against the principle of least surprise, I think we'd
> make you toggle the new behavior *off* rather than on, so all new users
> get the new, good behavior...
>
> geir
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Jan 15, 2004, at 6:48 PM, Nathan Bubna wrote:
> Geir Magnusson Jr said:
>> On Jan 15, 2004, at 5:59 PM, Nathan Bubna wrote:
>>> Geir Magnusson Jr said:
>>>> On Jan 15, 2004, at 5:38 PM, lloyd wrote:
>>>>> Mike Kienenberger wrote:
>>>>>> The more I use Velocity, the more I find myself writing hacks to
>>>>>> get
>>>>>> around the inability of Velocity to handle nulls as a context
>>>>>> attribute value.
>>>>>> Over the last half-year I've been subscribed to the mailing list,
>>>>>> I've seen comments that suggest the current behavior can't be
>>>>>> changed
>>>>>> because it'd break backwards compatiblity.
>>>>>> Is there anyone on this mailing list that depends on context
>>>>>> attributes not being set to null when the RHS evalutes to null?
>>>>>> Or are we all silently suffering because of some mythical or
>>>>>> implausible use case that doesn't exist?
>>>>>
>>>>> i realize i'm coming to this a little late - what's the latest
>>>>> thinking on it?
>>>>>
>>>>> i agree 100% that the null values problem is a BIG impediment to
>>>>> writing sane templates. i've been silent on the list for a long
>>>>> time
>>>>> because velocity mostly gives me everything i need, but i'm working
>>>>> on
>>>>> a template that works with a deeply hierarchical object, with a lot
>>>>> of
>>>>> levels to iterate over, and *all* the elements at all levels can
>>>>> have
>>>>> null values. lots of checks for nulls and #if blocks that
>>>>> contribute
>>>>> nothing but confusion...
>>>>>
>>>>> if a value is null, it should be *null*, not the previous value
>>>>> :-)
>>>>
>>>> Question : if #set could make LHS == null, would anything break in
>>>> existing templates? It's a one line fix if not... :)
>>>
>>> personally, it might break the hacks i've used to get around this
>>> "feature" in
>>> the past. that's ok with me, but i don't know about other people.
>>>
>>> again, i think it'd be best to have a velocity.properties setting
>>> that
>>> toggles
>>> this behavior. just set the default to the old behavior, and then we
>>> needn't
>>> worry about BC.
>>
>> While it goes against the principle of least surprise, I think we'd
>> make you toggle the new behavior *off* rather than on, so all new
>> users
>> get the new, good behavior...
>
> sounds great to me. i was just trying to make a concession to better
> the
> chances that this would happen. :)
>
:)
either one is compelling. Not breaking anything now via turning on the
new behavior w/ a switch is nice, but then people continue to do
handstands to get around it in new projects...
geir
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr said:
> On Jan 15, 2004, at 5:59 PM, Nathan Bubna wrote:
> > Geir Magnusson Jr said:
> >> On Jan 15, 2004, at 5:38 PM, lloyd wrote:
> >>> Mike Kienenberger wrote:
> >>>> The more I use Velocity, the more I find myself writing hacks to get
> >>>> around the inability of Velocity to handle nulls as a context
> >>>> attribute value.
> >>>> Over the last half-year I've been subscribed to the mailing list,
> >>>> I've seen comments that suggest the current behavior can't be
> >>>> changed
> >>>> because it'd break backwards compatiblity.
> >>>> Is there anyone on this mailing list that depends on context
> >>>> attributes not being set to null when the RHS evalutes to null?
> >>>> Or are we all silently suffering because of some mythical or
> >>>> implausible use case that doesn't exist?
> >>>
> >>> i realize i'm coming to this a little late - what's the latest
> >>> thinking on it?
> >>>
> >>> i agree 100% that the null values problem is a BIG impediment to
> >>> writing sane templates. i've been silent on the list for a long time
> >>> because velocity mostly gives me everything i need, but i'm working
> >>> on
> >>> a template that works with a deeply hierarchical object, with a lot
> >>> of
> >>> levels to iterate over, and *all* the elements at all levels can have
> >>> null values. lots of checks for nulls and #if blocks that contribute
> >>> nothing but confusion...
> >>>
> >>> if a value is null, it should be *null*, not the previous value :-)
> >>
> >> Question : if #set could make LHS == null, would anything break in
> >> existing templates? It's a one line fix if not... :)
> >
> > personally, it might break the hacks i've used to get around this
> > "feature" in
> > the past. that's ok with me, but i don't know about other people.
> >
> > again, i think it'd be best to have a velocity.properties setting that
> > toggles
> > this behavior. just set the default to the old behavior, and then we
> > needn't
> > worry about BC.
>
> While it goes against the principle of least surprise, I think we'd
> make you toggle the new behavior *off* rather than on, so all new users
> get the new, good behavior...
sounds great to me. i was just trying to make a concession to better the
chances that this would happen. :)
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Jan 15, 2004, at 5:59 PM, Nathan Bubna wrote:
> Geir Magnusson Jr said:
>> On Jan 15, 2004, at 5:38 PM, lloyd wrote:
>>> Mike Kienenberger wrote:
>>>> The more I use Velocity, the more I find myself writing hacks to get
>>>> around the inability of Velocity to handle nulls as a context
>>>> attribute value.
>>>> Over the last half-year I've been subscribed to the mailing list,
>>>> I've seen comments that suggest the current behavior can't be
>>>> changed
>>>> because it'd break backwards compatiblity.
>>>> Is there anyone on this mailing list that depends on context
>>>> attributes not being set to null when the RHS evalutes to null?
>>>> Or are we all silently suffering because of some mythical or
>>>> implausible use case that doesn't exist?
>>>
>>> i realize i'm coming to this a little late - what's the latest
>>> thinking on it?
>>>
>>> i agree 100% that the null values problem is a BIG impediment to
>>> writing sane templates. i've been silent on the list for a long time
>>> because velocity mostly gives me everything i need, but i'm working
>>> on
>>> a template that works with a deeply hierarchical object, with a lot
>>> of
>>> levels to iterate over, and *all* the elements at all levels can have
>>> null values. lots of checks for nulls and #if blocks that contribute
>>> nothing but confusion...
>>>
>>> if a value is null, it should be *null*, not the previous value :-)
>>
>> Question : if #set could make LHS == null, would anything break in
>> existing templates? It's a one line fix if not... :)
>
> personally, it might break the hacks i've used to get around this
> "feature" in
> the past. that's ok with me, but i don't know about other people.
>
> again, i think it'd be best to have a velocity.properties setting that
> toggles
> this behavior. just set the default to the old behavior, and then we
> needn't
> worry about BC.
While it goes against the principle of least surprise, I think we'd
make you toggle the new behavior *off* rather than on, so all new users
get the new, good behavior...
geir
>
> Nathan Bubna
> nathan@esha.com
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-user-help@jakarta.apache.org
>
>
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr said:
> On Jan 15, 2004, at 5:38 PM, lloyd wrote:
> > Mike Kienenberger wrote:
> >> The more I use Velocity, the more I find myself writing hacks to get
> >> around the inability of Velocity to handle nulls as a context
> >> attribute value.
> >> Over the last half-year I've been subscribed to the mailing list,
> >> I've seen comments that suggest the current behavior can't be changed
> >> because it'd break backwards compatiblity.
> >> Is there anyone on this mailing list that depends on context
> >> attributes not being set to null when the RHS evalutes to null?
> >> Or are we all silently suffering because of some mythical or
> >> implausible use case that doesn't exist?
> >
> > i realize i'm coming to this a little late - what's the latest
> > thinking on it?
> >
> > i agree 100% that the null values problem is a BIG impediment to
> > writing sane templates. i've been silent on the list for a long time
> > because velocity mostly gives me everything i need, but i'm working on
> > a template that works with a deeply hierarchical object, with a lot of
> > levels to iterate over, and *all* the elements at all levels can have
> > null values. lots of checks for nulls and #if blocks that contribute
> > nothing but confusion...
> >
> > if a value is null, it should be *null*, not the previous value :-)
>
> Question : if #set could make LHS == null, would anything break in
> existing templates? It's a one line fix if not... :)
personally, it might break the hacks i've used to get around this "feature" in
the past. that's ok with me, but i don't know about other people.
again, i think it'd be best to have a velocity.properties setting that toggles
this behavior. just set the default to the old behavior, and then we needn't
worry about BC.
Nathan Bubna
nathan@esha.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org
Re: POLL: null context attribute values
Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Jan 15, 2004, at 5:38 PM, lloyd wrote:
> Mike Kienenberger wrote:
>> The more I use Velocity, the more I find myself writing hacks to get
>> around the inability of Velocity to handle nulls as a context
>> attribute value.
>> Over the last half-year I've been subscribed to the mailing list,
>> I've seen comments that suggest the current behavior can't be changed
>> because it'd break backwards compatiblity.
>> Is there anyone on this mailing list that depends on context
>> attributes not being set to null when the RHS evalutes to null?
>> Or are we all silently suffering because of some mythical or
>> implausible use case that doesn't exist?
>
> i realize i'm coming to this a little late - what's the latest
> thinking on it?
>
> i agree 100% that the null values problem is a BIG impediment to
> writing sane templates. i've been silent on the list for a long time
> because velocity mostly gives me everything i need, but i'm working on
> a template that works with a deeply hierarchical object, with a lot of
> levels to iterate over, and *all* the elements at all levels can have
> null values. lots of checks for nulls and #if blocks that contribute
> nothing but confusion...
>
> if a value is null, it should be *null*, not the previous value :-)
Question : if #set could make LHS == null, would anything break in
existing templates? It's a one line fix if not... :)
--
Geir Magnusson Jr 203-247-1713(m)
geir@4quarters.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org