You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by specialist33 <sp...@grexengine.com> on 2005/01/06 21:32:34 UTC
Just a thought...foreach else ?
Looking through our templteas written over the last few months, we have
a LOT of cases of guarding on an empty foreach - empty means either
something went wrong OR we need an explicit "no results returned" message.
One of the problmes with the previous engine we used was that you
couldn't easily detect empty results sets, so we had lots of blanks
where users didn't realise something was SUPPOSED to be there.
So now we have:
#set( $result = some method to get the data )
#if( $result && $result.size() > 0 )
#foreach( $item in $result )
...
#end
#else
No results! Was expecting some here. The "some method" hasn't worked,
please tell an admin. Whatever. Your message goes here :)
#end
Which, I realised, would work much more nicely as:
#foreach( $r in $result )
...
#else
No results found. Error message. Etc.
#end
Now, not only does this make a lot of sense and cut out a lot of typing
but it has another handy feature: it removes the explicit "size()".
Unfortunately, Sun are poor at their own standards, and on some data you
have "length()" on others "length" on others "size()" - but NONE of
these are valid javabeans (you do sometimes see "getSize()" too but I
can't think of an example in a Sun API right now...).
So, $result.size doesn't work and you must have the () - which looks
very strange if you're using the beanshell shortcuts all over the rest
of hte template.
We had a LOT of bugs where people didn't realise this, or saw the () and
thought it was a mistake, seeing as nothing else had it. Even I made the
mistake a couple of times (weeks apart) before I memorized it.
So...if we encoded the algorithm for picking legnths/sizes and checking
if > 0 (where null ref is treated as 0, which is mathematically accurate
:)) then we remove this convoluted and irritating and confusing (but
short!) algorihtm from the heads of all the VTL users and put it into
the engine.
PS sorry if this has already been proposed, but I had a quick search and
didn't notice it anywhere
Thoughts? Should be quick n easy to implement I suspect if you're
already familiar with the VTL code?
PPS don't ask me to fill a BZ bug. When you remove the account-creation
BS so I don't have to faff about creating an account, waiting for an
email, etc, I'll use BZ. Until then - no way. Honestly I would be *very*
happy to file RFE's directly if there were no hassle...
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Just a thought...foreach else ?
Posted by Mike Kienenberger <mk...@alaska.net>.
#foreach #else #end would have saved me a bit of work the last couple of
days.
And helped me avoid the problem of leaving out the "$result &&" part of the
#if statement, which I did earlier today.
-Mike
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: Just a thought...foreach else ?
Posted by Tim Colson <tc...@cisco.com>.
Nathan wrote:
> i've thought about suggesting this in the past as well. it
> would be very cool.
Heh heh... 3 in favor, so far only one against. Have fun implementing. ;-)
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Just a thought...foreach else ?
Posted by Nathan Bubna <nb...@gmail.com>.
i've thought about suggesting this in the past as well. it would be very cool.
On Thu, 6 Jan 2005 13:21:27 -0800, Will Glass-Husain <wg...@forio.com> wrote:
> That's a clever idea for a shortcut. I use the #if / #foreach combination
> all the time. It's not a big deal, but the multiple #end can be confusing.
>
> WILL
>
> ----- Original Message -----
> From: "specialist33" <sp...@grexengine.com>
> To: "Velocity Developers List" <ve...@jakarta.apache.org>
> Sent: Thursday, January 06, 2005 12:32 PM
> Subject: Just a thought...foreach else ?
>
> > Looking through our templteas written over the last few months, we have a
> > LOT of cases of guarding on an empty foreach - empty means either
> > something went wrong OR we need an explicit "no results returned" message.
> >
> > One of the problmes with the previous engine we used was that you couldn't
> > easily detect empty results sets, so we had lots of blanks where users
> > didn't realise something was SUPPOSED to be there.
> >
> > So now we have:
> >
> > #set( $result = some method to get the data )
> >
> > #if( $result && $result.size() > 0 )
> >
> > #foreach( $item in $result )
> > ...
> > #end
> >
> > #else
> > No results! Was expecting some here. The "some method" hasn't worked,
> > please tell an admin. Whatever. Your message goes here :)
> > #end
> >
> > Which, I realised, would work much more nicely as:
> >
> > #foreach( $r in $result )
> > ...
> > #else
> > No results found. Error message. Etc.
> > #end
> >
> > Now, not only does this make a lot of sense and cut out a lot of typing
> > but it has another handy feature: it removes the explicit "size()".
> > Unfortunately, Sun are poor at their own standards, and on some data you
> > have "length()" on others "length" on others "size()" - but NONE of these
> > are valid javabeans (you do sometimes see "getSize()" too but I can't
> > think of an example in a Sun API right now...).
> >
> > So, $result.size doesn't work and you must have the () - which looks very
> > strange if you're using the beanshell shortcuts all over the rest of hte
> > template.
> >
> > We had a LOT of bugs where people didn't realise this, or saw the () and
> > thought it was a mistake, seeing as nothing else had it. Even I made the
> > mistake a couple of times (weeks apart) before I memorized it.
> >
> > So...if we encoded the algorithm for picking legnths/sizes and checking if
> > > 0 (where null ref is treated as 0, which is mathematically accurate :))
> > then we remove this convoluted and irritating and confusing (but short!)
> > algorihtm from the heads of all the VTL users and put it into the engine.
> >
> > PS sorry if this has already been proposed, but I had a quick search and
> > didn't notice it anywhere
> >
> > Thoughts? Should be quick n easy to implement I suspect if you're already
> > familiar with the VTL code?
> >
> > PPS don't ask me to fill a BZ bug. When you remove the account-creation BS
> > so I don't have to faff about creating an account, waiting for an email,
> > etc, I'll use BZ. Until then - no way. Honestly I would be *very* happy to
> > file RFE's directly if there were no hassle...
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Just a thought...foreach else ?
Posted by Claude Brisson <cl...@renegat.net>.
On Sun, 2005-01-09 at 23:43 +0100, Incze Lajos wrote:
> On Sun, Jan 09, 2005 at 11:51:44PM +0900, Shinobu Kawai wrote:
> > Hi guys,
> >
> > > ah, i see what you're saying. hmm. perhaps it would help to change
> > > perspective. rather than see this as a true/false type evaluation,
> > > see it as a render/no-render situation. then the template engine is
> > > only responding to its own behavior rather than evaluating an external
> > > condition. in other words, it says "i didn't render this, so i should
> > > render this instead" (apologies for the anthropomorphizing).
> >
> > I'm +1 for Nathan's suggestion. It's simple, easy-to-understand, and
> > I don't see any backwards-compatibility issues on it (not that I saw
> > any in the first place).
> >
> > So the conditions for the #else part to be rendered would be one of:
> > - there were no elements to render
> > - the introspector failed to get an iterator
> > Am I getting this right?
> >
>
> Seems to be all right, but in this case it would be nice to reword
> the guides in this sense. (#if #elseif #else - #foreach #else, as
> a render/no-render decision point, which is intuitively well known,
> but the usual semantics of IF, ELSE et al. supresses that sense.)
The render/no-render paradigm has nothing to do with #if #elseif #else.
But your remark is somewhat interesting, still one could consider the
exact opposite, hence using #foreach #elseif. Only mentionning it,
certainly not very k.i.s.s.able (hum) and easily reachable with an #if
inside the #else block of the #foreach, but at least not disturbing and
semantically consistent. Well, just some sort of lowcost inoffensive
hack for developers and/or second importance debate for purists about
mixing #if and #foreach paradigms, but anyway I digress. What about
having a #schmoo directive that prints a fortune ?
And of course you're right, the day guides will speak of #foreach #else,
the render/no-render terminology should be explicitely used.
Claude
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Just a thought...foreach else ?
Posted by Incze Lajos <in...@axelero.hu>.
On Sun, Jan 09, 2005 at 11:51:44PM +0900, Shinobu Kawai wrote:
> Hi guys,
>
> > ah, i see what you're saying. hmm. perhaps it would help to change
> > perspective. rather than see this as a true/false type evaluation,
> > see it as a render/no-render situation. then the template engine is
> > only responding to its own behavior rather than evaluating an external
> > condition. in other words, it says "i didn't render this, so i should
> > render this instead" (apologies for the anthropomorphizing).
>
> I'm +1 for Nathan's suggestion. It's simple, easy-to-understand, and
> I don't see any backwards-compatibility issues on it (not that I saw
> any in the first place).
>
> So the conditions for the #else part to be rendered would be one of:
> - there were no elements to render
> - the introspector failed to get an iterator
> Am I getting this right?
>
Seems to be all right, but in this case it would be nice to reword
the guides in this sense. (#if #elseif #else - #foreach #else, as
a render/no-render decision point, which is intuitively well known,
but the usual semantics of IF, ELSE et al. supresses that sense.)
incze
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Just a thought...foreach else ?
Posted by Shinobu Kawai <sh...@gmail.com>.
Hi guys,
> ah, i see what you're saying. hmm. perhaps it would help to change
> perspective. rather than see this as a true/false type evaluation,
> see it as a render/no-render situation. then the template engine is
> only responding to its own behavior rather than evaluating an external
> condition. in other words, it says "i didn't render this, so i should
> render this instead" (apologies for the anthropomorphizing).
I'm +1 for Nathan's suggestion. It's simple, easy-to-understand, and
I don't see any backwards-compatibility issues on it (not that I saw
any in the first place).
So the conditions for the #else part to be rendered would be one of:
- there were no elements to render
- the introspector failed to get an iterator
Am I getting this right?
Best regards,
-- Shinobu
--
Shinobu "Kawai" Yoshida <sh...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Just a thought...foreach else ?
Posted by Nathan Bubna <nb...@gmail.com>.
oops, only sent this to Tim the first time around...
On Thu, 6 Jan 2005 16:46:35 -0700, Tim Colson <tc...@cisco.com> wrote:
> > ;-) hah. bet you never thought that would be used in favor of adding
> > a feature!
> Indeed. ;-)
>
> > the #else statement is rendered anytime the #foreach doesn't render
> > its innards for whatever reason. i think we can all very easily agree
> > on that!
> Hmm... didn't you once argue that null isn't the same as "no results"? Or
> was that me? ;-)
i honestly don't recall. but i wouldn't put anything past me. :)
> So if #foreach ($result in $thingy.foo.results) dies when foo is null, that
> means semantically "no results".
>
> Smells like biz logic weirdness to me.
>
> > i don't see how doing #else
> > is any more business logic than your example.
> Your example: template engine makes the decision on what means True/False.
> My example: template engine just tests a Boolean for true/false.
>
> Less magic in mine than yours.
ah, i see what you're saying. hmm. perhaps it would help to change
perspective. rather than see this as a true/false type evaluation,
see it as a render/no-render situation. then the template engine is
only responding to its own behavior rather than evaluating an external
condition. in other words, it says "i didn't render this, so i should
render this instead" (apologies for the anthropomorphizing).
> > and even if it is, i've always tended to side with elegance over
> > pure-MVC-ism (thus my interest in Pull-MVC and VelocityTools). ;-)
>
> I always tend to side with keeping the templates dead simple. Adding a
> #foreach/#else smells like syntactic sugar that can be accomplished in the
> existing system with less uncertainty on the rules.
i don't think there need be any uncertainty. it is simple. if we
don't render the loop contents, we render the #else contents instead.
it is purely a view decision. and while it does add "syntactic sugar"
to the template *language*, the actual templates will become cleaner
and simpler.
> Another way -- I don't like the idea of telling a Template author that "#if
> #else" is triggered whenever "$results is empty... or maybe null... or well,
> if anything in there just plain blows up... or some other mystery buried in
> the Velocity Engine"
whether $results is empty or null or invalid still doesn't matter to
our hypothetical template author. all that matters is that there are
no results to be rendered.
> > still the real deciding factor will be whether anyone steps up to
> > scratch this itch with a patch. i wish i could say i would, but i
> > know i won't ever get to it.
> Ha -- well, since the dude who suggested it won't lower himself to login to
> bugzilla... I doubt you'll see a patch entered by him. <grin>
>
> But it seems other folks like the idea too... so maybe they'll scratch.
i can hope! (and you can dread? ;-)
> Cheers,
> Timo
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: Just a thought...foreach else ?
Posted by Tim Colson <tc...@cisco.com>.
> Which means we get something better than Perl? :)
:-) I meant that "even perl isn't that wacky... and believe me, perl IS
wacky" ;-)
Honestly curious -- has anybody seen this paradigm in -any- other lang?
Cheers,
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Just a thought...foreach else ?
Posted by Shinobu Kawai <sh...@gmail.com>.
Hi,
> > > That's a clever idea for a shortcut.
> > Agree it's interesting, but I'm unsure it will be easy to agree on what
> > constitutes "true/false" to trigger the #else. Plus, well, the paradigm is a
> > bit wacky. I mean, even perl doesn't have an 'else' clause for a loop
> > construct. <grin>
>
> as one former pillar of this community used to say: "this isn't Perl"
> ;-) hah. bet you never thought that would be used in favor of adding
> a feature!
Which means we get something better than Perl? :)
> still the real deciding factor will be whether anyone steps up to
> scratch this itch with a patch. i wish i could say i would, but i
> know i won't ever get to it.
Wouldn't this involve moving o.a.v.r.directive.Foreach to
o.a.v.r.parser.node.ASTForeachStatement + more? I wonder how much
trouble it would be to support a new multi-part directive type? I
mean, support adding multi-part directives without editing parser.jjt.
Best regards,
-- Shinobu
--
Shinobu "Kawai" Yoshida <sh...@gmail.com>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Just a thought...foreach else ?
Posted by specialist33 <sp...@grexengine.com>.
Tim Colson wrote:
>
> Your example: template engine makes the decision on what means True/False.
> My example: template engine just tests a Boolean for true/false.
>
> Less magic in mine than yours.
>
No. V already has this concept that "null = false; notnull == true".
That's where the "if( $result ..." comes from: this is the only easy way
to handle nulls in V (that i've found so far; the faffing about with
trying to simulate "if( x == null )" in V, and support it with users,
evetnually made me give up and just use the if() test.
Otherwise...I wouldn't have suggested it. I though it was a good idea
because it is actually consistent with design decisions already made in
V (which I'm not sure I agree with in the first palce, but now they're
there I'm happy to run with them...)
> Ha -- well, since the dude who suggested it won't lower himself to login to
> bugzilla... I doubt you'll see a patch entered by him. <grin>
I've contributed to many o-s projects, but got fed up of the amount of
time I wasted creating one million + 2 BZ accounts and mailing list
confirmations etc. It's a sign of my delight with V that I (eventually)
prodded the company to register on the mailing list (this is a group
mailing addresss so it goes to multiple people here).
Frequently, it takes MORE time to register with BZ or the majordomo
(espeically with slow confirmation systems) than it does to type uip the
damn RFE or bug report! That takes the piss, and I refuse to support
this group-think stupidity where every project feels so self-important
as to force user-accounts on everyone. The truth is that most of them
have no need for it, and are just irritating people; the silent majority
who don't contribute because there are just slightly sufficient hurdles
to make it a PITA.
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Just a thought...foreach else ?
Posted by Mike Kienenberger <mk...@alaska.net>.
Tim Colson <tc...@cisco.com> wrote:
> Hmm... didn't you once argue that null isn't the same as "no results"? Or
> was that me? ;-)
Actually, it was me :)
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: Just a thought...foreach else ?
Posted by Tim Colson <tc...@cisco.com>.
> ;-) hah. bet you never thought that would be used in favor of adding
> a feature!
Indeed. ;-)
> the #else statement is rendered anytime the #foreach doesn't render
> its innards for whatever reason. i think we can all very easily agree
> on that!
Hmm... didn't you once argue that null isn't the same as "no results"? Or
was that me? ;-)
So if #foreach ($result in $thingy.foo.results) dies when foo is null, that
means semantically "no results".
Smells like biz logic weirdness to me.
> i don't see how doing #else
> is any more business logic than your example.
Your example: template engine makes the decision on what means True/False.
My example: template engine just tests a Boolean for true/false.
Less magic in mine than yours.
> and even if it is, i've always tended to side with elegance over
> pure-MVC-ism (thus my interest in Pull-MVC and VelocityTools). ;-)
I always tend to side with keeping the templates dead simple. Adding a
#foreach/#else smells like syntactic sugar that can be accomplished in the
existing system with less uncertainty on the rules.
Another way -- I don't like the idea of telling a Template author that "#if
#else" is triggered whenever "$results is empty... or maybe null... or well,
if anything in there just plain blows up... or some other mystery buried in
the Velocity Engine"
> still the real deciding factor will be whether anyone steps up to
> scratch this itch with a patch. i wish i could say i would, but i
> know i won't ever get to it.
Ha -- well, since the dude who suggested it won't lower himself to login to
bugzilla... I doubt you'll see a patch entered by him. <grin>
But it seems other folks like the idea too... so maybe they'll scratch.
Cheers,
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: Just a thought...foreach else ?
Posted by Tim Colson <tc...@cisco.com>.
> | Maybe one can invent a more appropriate keyword instead
> | of overloading "else" (e.g. "empty" or sg. like that).
>
> #onempty / #ifempty / #empty
> #onnull / #ifnull / #null
lol... great example of why I've been muttering in the corner about not
having the same def'n for what triggers #else.
#onEmpty is not semantically the same as #onNull
And neither one is the same semantic reason as
#onFailingToRenderForAnyGoofyReason <grin>
Ahhh... I long for the days when we all argued over something I really want
-- better whitespace handling. ;-)
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: Just a thought...foreach else ?
Posted by Claude Brisson <cl...@renegat.net>.
On Mon, 2005-01-10 at 16:22 -0300, Gonzalo Diethelm wrote:
> > | Maybe one can invent a more appropriate keyword instead
> > | of overloading "else" (e.g. "empty" or sg. like that).
> >
> > #onempty / #ifempty / #empty
> >
> > #onnull / #ifnull / #null
>
> #otherwise
>
#nevertheless
#*someone had to do it*#
--
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: Just a thought...foreach else ?
Posted by Gonzalo Diethelm <go...@aditiva.com>.
> | Maybe one can invent a more appropriate keyword instead
> | of overloading "else" (e.g. "empty" or sg. like that).
>
> #onempty / #ifempty / #empty
>
> #onnull / #ifnull / #null
#otherwise
--
Gonzalo Diethelm
gonzalo.diethelm@aditiva.com
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Just a thought...foreach else ?
Posted by Endre Stølsvik <En...@Stolsvik.com>.
On Fri, 7 Jan 2005, Incze Lajos wrote:
| > > #if ($SHOW_RESULTS)
| > > #foreach ($result in $list_of_results)
| > > $result
| > > #end
| > > #else
| > > No results to show!
| > > #end
| >
| > i don't see how doing
| >
| > #foreach( $result in $list_of_results )
| > $result
| > #else
| > No results to show!
| > #end
|
| Maybe one can invent a more appropriate keyword instead
| of overloading "else" (e.g. "empty" or sg. like that).
#onempty / #ifempty / #empty
#onnull / #ifnull / #null
Endre
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Just a thought...foreach else ?
Posted by Incze Lajos <in...@axelero.hu>.
> > #if ($SHOW_RESULTS)
> > #foreach ($result in $list_of_results)
> > $result
> > #end
> > #else
> > No results to show!
> > #end
>
> i don't see how doing
>
> #foreach( $result in $list_of_results )
> $result
> #else
> No results to show!
> #end
Maybe one can invent a more appropriate keyword instead
of overloading "else" (e.g. "empty" or sg. like that).
incze
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Just a thought...foreach else ?
Posted by Nathan Bubna <nb...@gmail.com>.
On Fri, 7 Jan 2005 08:55:05 -0700, Tim Colson <tc...@cisco.com> wrote:
> > I go back and forth. Sometimes I put the "no results found"
> > outside of the
> > table. But often it's nice to do it inside (and keep the header) like
> > specialist33. Depends on the layout.
> Agreed -- the point I was trying to make, poorly, was that there are use
> cases (ex. outside the table) where the template author won't be able to use
> the #empty trick. So they will probably have two parallel condition tests,
> which is generally not a great idea.
>
> Here's another use case where the expression gives back either a list OR a
> single result.
>
> #if ($Searcher.thereIsOnlyOne)
> Only one result == $Searcher.result.name
> #else
> #foreach ($thingy in $Searcher.result)
> $thingy.name
> #end
> #end
>
> For this case... #foreach#empty would probably not hit #empty... or maybe it
> would because if the Engine tried Searcher.getResult().size() -- it would
> probably die.
and why should it hit #empty (or #else) in this example? there IS a
result; it isn't empty! let's not pretend that this is a use case
where #foreach/#else "doesn't work" when this is really just an
example where #foreach/#else *doesn't apply*. big difference.
> I have a very unique wheel. <grin>
>
> BTW -- nobody has suggested what happens for $thingy.foo.results when foo is
> null (i.e. is the #else rendered because a) list is empty, b) list is null,
> or c) the expresstion blows up but has nothing to do remotely with results)
have too! :) the #else is rendered because the #foreach block was
not. we are not changing the behavior of the #foreach block and the
rules for what happens when foo is null for $thingy.foo.results is
used in #foreach are not under debate here. those are already
established and entirely tangential to the conversation. we are
simply talking about adding the ability to neatly and cleanly specify
an alternate block to be rendered in the cases (whatever they may be)
where the #foreach block is not.
> Cheers,
> Timo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Just a thought...foreach else ?
Posted by Nathan Bubna <nb...@gmail.com>.
hmm. at first i half-liked the #empty suggestion. but then i looked
at your example. i'd rather stick with #else. it's conceptually the
same as #if/#else ("if we don't render this, render this instead") so
i think we should stick with the same terms instead of making new ones
to learn. k.i.s.s.
On Thu, 6 Jan 2005 19:47:54 -0800, Will Glass-Husain <wg...@forio.com> wrote:
> I go back and forth. Sometimes I put the "no results found" outside of the
> table. But often it's nice to do it inside (and keep the header) like
> specialist33. Depends on the layout.
>
> Incidentally, I think I'd prefer an alternatate directive, to avoid
> confusion. Maybe #empty?
>
> #foreach ($a in $list)
> a row of items
> #empty
> nothing found
> #end
>
> Anyway, this is a significant change to the parser (it requires a change to
> Parser.jjt, rather than just being implemented as a custom directive). So
> we should probably let this stew a bit before doing anything radical.
>
> WILL
>
> ----- Original Message -----
> From: "specialist33" <sp...@grexengine.com>
> To: "Velocity Developers List" <ve...@jakarta.apache.org>
> Sent: Thursday, January 06, 2005 6:34 PM
> Subject: Re: Just a thought...foreach else ?
>
> > Tim Colson wrote:
> >>>Exactly. The thing is trivial to read and understand
> >>
> >> Trivial, eh? Heh heh, well so trivial that you then present a null versus
> >> empty case... and dismiss it because it's probably "less common". ;-)
> >
> > It is "trivial to read and understand" *AS PRESENTED*.
> >
> > In the null vs. empty case, a more powerful concept which WOULD NOT WORK
> > using the "trivial to read and understand syntax" this in not the case.
> >
> >>>May I introduce you to "intelligent" views: they tell you when they were
> >>>fed invalid data.
> >>
> >> The view isn't doing it... the Velocity Engine is making the call. That's
> >> my
> >> concern.
> >
> > Conceptually. Sure, the view is being produced by V, but it's still a
> > view, in M/V/C terminology: it has no logic. It's just being a
> > particularly useful view, rather than a weak one.
> >
> >>
> >> But it does bring up another use case that this swank new #foreach/#else
> >> doesn't handle.
> >>
> >> Tables.
> >>
> >> #if ($SHOW_RESULTS)
> >> <TABLE>
> >> #foreach ($thingy in $results) $thingy
> >> #end
> >> </TABLE>
> >>
> >> #else
> >> No soup for you!
> >> #end
> >>
> >>
> >> Point is -- you need to put in the magic "do results exist" test outside
> >> the
> >> foreach... so your #else won't help you here, and you'll end up with dual
> >> logic anyway. <grin>
> >> >
> >
> > We use:
> >
> > <table>
> > <tr>
> > headers row
> > </tr>
> > #foreach
> > do all the rows
> > #else
> > <td colspan="5"> No results found </td>
> > #end
> >
> > (used my proposed syntax for conveninece, but you get the idea :)).
> >
> > It looks nice: it shows you what information you would have had, had there
> > been any information.
> >
> >> I agree we shouldn't invent the same things... but the trick is that we
> >> all
> >> must have the same, exact, identical wheel.
> >
> > Which is why I asked. So far, you've not convinced me otherwise :).
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: Just a thought...foreach else ?
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
>By my count, I've got more use cases where it doesn't work than ones where
it does. Lol. Shall I keep coming >up with cases? :-)
heh, not on my account!
>Over the years there are folks who use Velocity for a few weeks and pop on
the list to say "This is GREAT >STUFF!... but... it'd be awesome if it had
Feature X! Somebody should code Feature X and then Velocity would be
>PERFECT [for me]!"
>Then there are folks who say, "well... it works fairly well already, and
we'd like to keep the core simple and >small, can't you do this with a macro
or tool? Oh, you can. Great. Moving on..." ***
>Me -- I'm just in that latter camp. Call me crufty. :-P
Now _that's_ a relevant point, imho :-)
Of course these suggestions need to be evaluated on a case by case basis and
not dismissed right away with references to usecases that don't benefit from
the feature, while there are many that would ... I am all for k.i.s.s. - as
for this particular case, I for one don't really care either way :-)
cheers,
Marinó
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: Just a thought...foreach else ?
Posted by Tim Colson <tc...@cisco.com>.
> if you have a "very unique wheel" - don't use the feature!
> The fact that
> the feature isn't useful in every single usecase is hardly
> reason to drop it
I'm not saying drop it, if somebody else codes it, that's fine... I'll only
cringe if/when a template designer uses it. ;-)
I'm over here on the unfashionable end of the discussion pointing out use
cases where #empty doesn't seem all that useful. I come up with them, but
others keep saying, "Well, yeah...but it'd still be oh so useful for
'everybody' else." <grin>
By my count, I've got more use cases where it doesn't work than ones where
it does. Lol. Shall I keep coming up with cases? :-)
Over the years there are folks who use Velocity for a few weeks and pop on
the list to say "This is GREAT STUFF!... but... it'd be awesome if it had
Feature X! Somebody should code Feature X and then Velocity would be PERFECT
[for me]!"
Then there are folks who say, "well... it works fairly well already, and
we'd like to keep the core simple and small, can't you do this with a macro
or tool? Oh, you can. Great. Moving on..." ***
Me -- I'm just in that latter camp. Call me crufty. :-P
Timo
*** Humourously: At that point, the User forks their own project, creates
Feature X and all of the Velocity user base flocks to their new insanely
cool template engine... or not. <grin>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: Just a thought...foreach else ?
Posted by "Marinó A. Jónsson" <ma...@centrum.is>.
>Agreed -- the point I was trying to make, poorly, was that there are use
cases (ex. outside the table) where >>the template author won't be able to
use the #empty trick. So they will probably have two parallel condition
>tests, which is generally not a great idea.
>Here's another use case where the expression gives back either a list OR a
single result.
>#if ($Searcher.thereIsOnlyOne)
> Only one result == $Searcher.result.name #else #foreach ($thingy in
$Searcher.result)
> $thingy.name
> #end
>#end
>For this case... #foreach#empty would probably not hit #empty... or maybe
it would because if the Engine tried >Searcher.getResult().size() -- it
would probably die.
>I have a very unique wheel. <grin>
if you have a "very unique wheel" - don't use the feature! The fact that
the feature isn't useful in every single usecase is hardly reason to drop it
;)
cheers,
Marinó
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: Just a thought...foreach else ?
Posted by Tim Colson <tc...@cisco.com>.
> I go back and forth. Sometimes I put the "no results found"
> outside of the
> table. But often it's nice to do it inside (and keep the header) like
> specialist33. Depends on the layout.
Agreed -- the point I was trying to make, poorly, was that there are use
cases (ex. outside the table) where the template author won't be able to use
the #empty trick. So they will probably have two parallel condition tests,
which is generally not a great idea.
Here's another use case where the expression gives back either a list OR a
single result.
#if ($Searcher.thereIsOnlyOne)
Only one result == $Searcher.result.name
#else
#foreach ($thingy in $Searcher.result)
$thingy.name
#end
#end
For this case... #foreach#empty would probably not hit #empty... or maybe it
would because if the Engine tried Searcher.getResult().size() -- it would
probably die.
I have a very unique wheel. <grin>
BTW -- nobody has suggested what happens for $thingy.foo.results when foo is
null (i.e. is the #else rendered because a) list is empty, b) list is null,
or c) the expresstion blows up but has nothing to do remotely with results)
Cheers,
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Just a thought...foreach else ?
Posted by Will Glass-Husain <wg...@forio.com>.
I go back and forth. Sometimes I put the "no results found" outside of the
table. But often it's nice to do it inside (and keep the header) like
specialist33. Depends on the layout.
Incidentally, I think I'd prefer an alternatate directive, to avoid
confusion. Maybe #empty?
#foreach ($a in $list)
a row of items
#empty
nothing found
#end
Anyway, this is a significant change to the parser (it requires a change to
Parser.jjt, rather than just being implemented as a custom directive). So
we should probably let this stew a bit before doing anything radical.
WILL
----- Original Message -----
From: "specialist33" <sp...@grexengine.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: Thursday, January 06, 2005 6:34 PM
Subject: Re: Just a thought...foreach else ?
> Tim Colson wrote:
>>>Exactly. The thing is trivial to read and understand
>>
>> Trivial, eh? Heh heh, well so trivial that you then present a null versus
>> empty case... and dismiss it because it's probably "less common". ;-)
>
> It is "trivial to read and understand" *AS PRESENTED*.
>
> In the null vs. empty case, a more powerful concept which WOULD NOT WORK
> using the "trivial to read and understand syntax" this in not the case.
>
>>>May I introduce you to "intelligent" views: they tell you when they were
>>>fed invalid data.
>>
>> The view isn't doing it... the Velocity Engine is making the call. That's
>> my
>> concern.
>
> Conceptually. Sure, the view is being produced by V, but it's still a
> view, in M/V/C terminology: it has no logic. It's just being a
> particularly useful view, rather than a weak one.
>
>>
>> But it does bring up another use case that this swank new #foreach/#else
>> doesn't handle.
>>
>> Tables.
>>
>> #if ($SHOW_RESULTS)
>> <TABLE>
>> #foreach ($thingy in $results) $thingy
>> #end
>> </TABLE>
>>
>> #else
>> No soup for you!
>> #end
>>
>>
>> Point is -- you need to put in the magic "do results exist" test outside
>> the
>> foreach... so your #else won't help you here, and you'll end up with dual
>> logic anyway. <grin>
>> >
>
> We use:
>
> <table>
> <tr>
> headers row
> </tr>
> #foreach
> do all the rows
> #else
> <td colspan="5"> No results found </td>
> #end
>
> (used my proposed syntax for conveninece, but you get the idea :)).
>
> It looks nice: it shows you what information you would have had, had there
> been any information.
>
>> I agree we shouldn't invent the same things... but the trick is that we
>> all
>> must have the same, exact, identical wheel.
>
> Which is why I asked. So far, you've not convinced me otherwise :).
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Just a thought...foreach else ?
Posted by specialist33 <sp...@grexengine.com>.
Tim Colson wrote:
>>Exactly. The thing is trivial to read and understand
>
> Trivial, eh? Heh heh, well so trivial that you then present a null versus
> empty case... and dismiss it because it's probably "less common". ;-)
It is "trivial to read and understand" *AS PRESENTED*.
In the null vs. empty case, a more powerful concept which WOULD NOT WORK
using the "trivial to read and understand syntax" this in not the case.
>>May I introduce you to "intelligent" views: they tell you
>>when they were fed invalid data.
>
> The view isn't doing it... the Velocity Engine is making the call. That's my
> concern.
Conceptually. Sure, the view is being produced by V, but it's still a
view, in M/V/C terminology: it has no logic. It's just being a
particularly useful view, rather than a weak one.
>
> But it does bring up another use case that this swank new #foreach/#else
> doesn't handle.
>
> Tables.
>
> #if ($SHOW_RESULTS)
> <TABLE>
> #foreach ($thingy in $results)
> $thingy
> #end
> </TABLE>
>
> #else
> No soup for you!
> #end
>
>
> Point is -- you need to put in the magic "do results exist" test outside the
> foreach... so your #else won't help you here, and you'll end up with dual
> logic anyway. <grin>
> >
We use:
<table>
<tr>
headers row
</tr>
#foreach
do all the rows
#else
<td colspan="5"> No results found </td>
#end
(used my proposed syntax for conveninece, but you get the idea :)).
It looks nice: it shows you what information you would have had, had
there been any information.
> I agree we shouldn't invent the same things... but the trick is that we all
> must have the same, exact, identical wheel.
Which is why I asked. So far, you've not convinced me otherwise :).
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: Just a thought...foreach else ?
Posted by Tim Colson <tc...@cisco.com>.
> Exactly. The thing is trivial to read and understand
Trivial, eh? Heh heh, well so trivial that you then present a null versus
empty case... and dismiss it because it's probably "less common". ;-)
> May I introduce you to "intelligent" views: they tell you
> when they were fed invalid data.
The view isn't doing it... the Velocity Engine is making the call. That's my
concern.
> message (usually). I think if you had this problem, of the silently
> vanishing lists that don't even appear as empty lists because HTML
Hold on a bit, mate. I run into this all the time... I just solve it
differently.
> It's OK with tables, where you've got the header row even with 0
> results. But it's still much nicer to avoid writing out all the code,
> several times, in every single template.
Hmm... not sure of your point there, friend.
But it does bring up another use case that this swank new #foreach/#else
doesn't handle.
Tables.
#if ($SHOW_RESULTS)
<TABLE>
#foreach ($thingy in $results)
$thingy
#end
</TABLE>
#else
No soup for you!
#end
Point is -- you need to put in the magic "do results exist" test outside the
foreach... so your #else won't help you here, and you'll end up with dual
logic anyway. <grin>
> Only if you believe that every single VTL user should
> re-invent the same wheel on every project - when it's a wheel that
> - we all want the same algorithm for
I agree we shouldn't invent the same things... but the trick is that we all
must have the same, exact, identical wheel.
Cheers,
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Just a thought...foreach else ?
Posted by ceo <ce...@grexengine.com>.
Nathan Bubna wrote:
> On Thu, 6 Jan 2005 15:37:18 -0700, Tim Colson <tc...@cisco.com> wrote:
>
>>>That's a clever idea for a shortcut.
>>
>>Agree it's interesting, but I'm unsure it will be easy to agree on what
>>constitutes "true/false" to trigger the #else. Plus, well, the paradigm is a
>>bit wacky. I mean, even perl doesn't have an 'else' clause for a loop
>>construct. <grin>
>
> as for what would trigger the #else, i should think that is obvious.
> the #else statement is rendered anytime the #foreach doesn't render
> its innards for whatever reason. i think we can all very easily agree
> on that!
>
Exactly. The thing is trivial to read and understand - principle of
least surprise: the else is evaluated precisely whenever the internals
are not. Both the result set being empty or being null will prevent the
internals from evaluating.
OK, it would be *nice* to have a trinary:
foreach
...
but-if-it-was-null
...
but-if-it-was-empty
but there is no *obvious* simple trivial way to do that off the top of
my head, and the need to differentiate between "result was null" and
"result was empty" is a lot less common than just needing to detect either.
In fact, the problem comes about partly because you HAVE to test both
just in order to test emptinees, otherwise you hit a
nullpointerexception (IIRC), so this is about simplifying a very common
process in several ways down to one that is both simple AND trivially
readable.
>
>>The rule for true/false smells like business logic... which I personally
What's business logic about it?
May I introduce you to "intelligent" views: they tell you when they were
fed invalid data. That's all that's happening here - you're not going to
branch off and render a completely different Database in the else (well,
not normally :)).
All you're doing is popping up a nice-n-friendly "no results found"
message (usually). I think if you had this problem, of the silently
vanishing lists that don't even appear as empty lists because HTML
silently non-renders empty lists then you would understand a bit better:
it is a major problem to have something not appear.
It's OK with tables, where you've got the header row even with 0
results. But it's still much nicer to avoid writing out all the code,
several times, in every single template.
>>
>>The backend can worry about the goofiness of java .length/size/size() and
Only if you believe that every single VTL user should re-invent the same
wheel on every project - when it's a wheel that
- we know many of us are going to need
- we all want the same algorithm for
no?
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Just a thought...foreach else ?
Posted by Nathan Bubna <nb...@gmail.com>.
On Thu, 6 Jan 2005 15:37:18 -0700, Tim Colson <tc...@cisco.com> wrote:
> > That's a clever idea for a shortcut.
> Agree it's interesting, but I'm unsure it will be easy to agree on what
> constitutes "true/false" to trigger the #else. Plus, well, the paradigm is a
> bit wacky. I mean, even perl doesn't have an 'else' clause for a loop
> construct. <grin>
as one former pillar of this community used to say: "this isn't Perl"
;-) hah. bet you never thought that would be used in favor of adding
a feature!
as for what would trigger the #else, i should think that is obvious.
the #else statement is rendered anytime the #foreach doesn't render
its innards for whatever reason. i think we can all very easily agree
on that!
> The rule for true/false smells like business logic... which I personally
> don't like putting in my templates, so I cringe at the idea of the Template
> Engine embedding it. :-(
>
> The backend can worry about the goofiness of java .length/size/size() and
> just set a simple:
> context.put("SHOW_RESULTS", new Boolean(myResultList.hasStuffInIt() &&
> user.isAuthorized() );
>
> #if ($SHOW_RESULTS)
> #foreach ($result in $list_of_results)
> $result
> #end
> #else
> No results to show!
> #end
i don't see how doing
#foreach( $result in $list_of_results )
$result
#else
No results to show!
#end
is any more business logic than your example.
and even if it is, i've always tended to side with elegance over
pure-MVC-ism (thus my interest in Pull-MVC and VelocityTools). ;-)
still the real deciding factor will be whether anyone steps up to
scratch this itch with a patch. i wish i could say i would, but i
know i won't ever get to it.
> And of course, that could be wrapped in a macro or two.
>
> Timo
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
RE: Just a thought...foreach else ?
Posted by Tim Colson <tc...@cisco.com>.
> That's a clever idea for a shortcut.
Agree it's interesting, but I'm unsure it will be easy to agree on what
constitutes "true/false" to trigger the #else. Plus, well, the paradigm is a
bit wacky. I mean, even perl doesn't have an 'else' clause for a loop
construct. <grin>
The rule for true/false smells like business logic... which I personally
don't like putting in my templates, so I cringe at the idea of the Template
Engine embedding it. :-(
The backend can worry about the goofiness of java .length/size/size() and
just set a simple:
context.put("SHOW_RESULTS", new Boolean(myResultList.hasStuffInIt() &&
user.isAuthorized() );
#if ($SHOW_RESULTS)
#foreach ($result in $list_of_results)
$result
#end
#else
No results to show!
#end
And of course, that could be wrapped in a macro or two.
Timo
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
Re: Just a thought...foreach else ?
Posted by Will Glass-Husain <wg...@forio.com>.
That's a clever idea for a shortcut. I use the #if / #foreach combination
all the time. It's not a big deal, but the multiple #end can be confusing.
WILL
----- Original Message -----
From: "specialist33" <sp...@grexengine.com>
To: "Velocity Developers List" <ve...@jakarta.apache.org>
Sent: Thursday, January 06, 2005 12:32 PM
Subject: Just a thought...foreach else ?
> Looking through our templteas written over the last few months, we have a
> LOT of cases of guarding on an empty foreach - empty means either
> something went wrong OR we need an explicit "no results returned" message.
>
> One of the problmes with the previous engine we used was that you couldn't
> easily detect empty results sets, so we had lots of blanks where users
> didn't realise something was SUPPOSED to be there.
>
> So now we have:
>
> #set( $result = some method to get the data )
>
> #if( $result && $result.size() > 0 )
>
> #foreach( $item in $result )
> ...
> #end
>
> #else
> No results! Was expecting some here. The "some method" hasn't worked,
> please tell an admin. Whatever. Your message goes here :)
> #end
>
> Which, I realised, would work much more nicely as:
>
> #foreach( $r in $result )
> ...
> #else
> No results found. Error message. Etc.
> #end
>
> Now, not only does this make a lot of sense and cut out a lot of typing
> but it has another handy feature: it removes the explicit "size()".
> Unfortunately, Sun are poor at their own standards, and on some data you
> have "length()" on others "length" on others "size()" - but NONE of these
> are valid javabeans (you do sometimes see "getSize()" too but I can't
> think of an example in a Sun API right now...).
>
> So, $result.size doesn't work and you must have the () - which looks very
> strange if you're using the beanshell shortcuts all over the rest of hte
> template.
>
> We had a LOT of bugs where people didn't realise this, or saw the () and
> thought it was a mistake, seeing as nothing else had it. Even I made the
> mistake a couple of times (weeks apart) before I memorized it.
>
> So...if we encoded the algorithm for picking legnths/sizes and checking if
> > 0 (where null ref is treated as 0, which is mathematically accurate :))
> then we remove this convoluted and irritating and confusing (but short!)
> algorihtm from the heads of all the VTL users and put it into the engine.
>
> PS sorry if this has already been proposed, but I had a quick search and
> didn't notice it anywhere
>
> Thoughts? Should be quick n easy to implement I suspect if you're already
> familiar with the VTL code?
>
> PPS don't ask me to fill a BZ bug. When you remove the account-creation BS
> so I don't have to faff about creating an account, waiting for an email,
> etc, I'll use BZ. Until then - no way. Honestly I would be *very* happy to
> file RFE's directly if there were no hassle...
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org