You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Andy Lee <ag...@earthlink.net> on 2002/11/04 06:57:45 UTC
discarding method return values
I have a question related to the recent one about forcing all
references to be quiet. I didn't see an answer in the docs, but feel
free to tell me "It's right there, you dope!"
I often want to discard the return values of methods. For example, I
might have:
#set( $myArray = [] )
$myArray.add(1)
$myArray.add(2)
$myArray.add(3)
Because add(Object) returns a boolean, this displays "true" three
times, which is not what I want. My first workaround was this:
#set( $ignore = $myArray.add(1) )
#set( $ignore = $myArray.add(2) )
#set( $ignore = $myArray.add(3) )
This works, but seeing the word #set bugged me because I really don't
want to set anything. My next workaround was to write a macro that
hides the #set:
#macro( silently $foo )
#set( $foo = $foo )
#end
(The reason for having the useless #set is that empty macros never
seem to get called. I'm guessing they get optimized away.)
Now I can do:
#silently( $myArray.add(1) )
#silently( $myArray.add(2) )
#silently( $myArray.add(3) )
I'm comfortable with this in many cases, but I wonder if it would be
awkwardly verbose in others.
Would it be worth adding syntax that causes references *never* to
print, regardless of their value? I.e., not only "quiet" but "mute"?
Something like...
$_myArray.add(1)
$_myHashMap.put("bus", "truck")
$_myStringBuffer.append($lastName)
...?
Maybe the underscore character is a bad choice, because it could look
like part of the variable name, even though it can't be. I kind of
like it because it connotes nothingness. But whatever.
--Andy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: discarding method return values
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 11/4/02 4:31 AM, "Christoph.Reck@dlr.de" <Ch...@dlr.de> wrote:
> I created a macro for this:
>
> #macro( call $foo )#if( $foo )#**##end#end
>
> since the #set(...) you used might cough and emit a log message when
> the call returns null.
>
> Since it is a major issue to keep velocity simple, we should not
> add another criptic feature. When you want to explicitly do something
> apart from normal, do it expicitly and with clear text.
>
> Still I believe Velocity-land would profit from a base library of
> extended directives and macros: $encode, #call, #local, etc.
And I think I ask every 6 months for contributions :)
Want to start it off?
--
Geir Magnusson Jr.
geirm@adeptra.com +1-203-355-2219 (w)
Adeptra Inc. +1-203-247-1713 (m)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: discarding method return values
Posted by Ch...@dlr.de.
I created a macro for this:
#macro( call $foo )#if( $foo )#**##end#end
since the #set(...) you used might cough and emit a log message when
the call returns null.
Since it is a major issue to keep velocity simple, we should not
add another criptic feature. When you want to explicitly do something
apart from normal, do it expicitly and with clear text.
Still I believe Velocity-land would profit from a base library of
extended directives and macros: $encode, #call, #local, etc.
Just my 2c...
Andy Lee wrote:
> I have a question related to the recent one about forcing all references
> to be quiet. I didn't see an answer in the docs, but feel free to tell
> me "It's right there, you dope!"
>
> I often want to discard the return values of methods. For example, I
> might have:
>
>
> #set( $myArray = [] )
> $myArray.add(1)
> $myArray.add(2)
> $myArray.add(3)
>
>
> Because add(Object) returns a boolean, this displays "true" three times,
> which is not what I want. My first workaround was this:
>
>
> #set( $ignore = $myArray.add(1) )
> #set( $ignore = $myArray.add(2) )
> #set( $ignore = $myArray.add(3) )
>
>
> This works, but seeing the word #set bugged me because I really don't
> want to set anything. My next workaround was to write a macro that
> hides the #set:
>
>
> #macro( silently $foo )
> #set( $foo = $foo )
> #end
>
>
> (The reason for having the useless #set is that empty macros never seem
> to get called. I'm guessing they get optimized away.)
>
> Now I can do:
>
>
> #silently( $myArray.add(1) )
> #silently( $myArray.add(2) )
> #silently( $myArray.add(3) )
>
>
> I'm comfortable with this in many cases, but I wonder if it would be
> awkwardly verbose in others.
>
> Would it be worth adding syntax that causes references *never* to print,
> regardless of their value? I.e., not only "quiet" but "mute"? Something
> like...
>
>
> $_myArray.add(1)
>
> $_myHashMap.put("bus", "truck")
>
> $_myStringBuffer.append($lastName)
>
>
> ...?
>
> Maybe the underscore character is a bad choice, because it could look
> like part of the variable name, even though it can't be. I kind of like
> it because it connotes nothingness. But whatever.
>
> --Andy
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
>
--
:) Christoph Reck
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: discarding method return values
Posted by Ch...@dlr.de.
Hi Andy,
I cas see some uses of velocity apart from MVC where you would
code values into a template... but that is another issue (where
a multi line set comes handy).
You example below just shows that you want to explicetaly call
the add method. OTOH the template processor does not know that
and thinks you want to display the result of that method call.
That is why I have stated previously in this thread that in such
cases you should do the call explicetely:
#macro( call $foo )#if( $foo )#**##end#end
## I used an empty copmment in the if-body since an earlyer version
## of velocity coughed when the #end directly followed the #if()
...
#set( $myLongWords = [] )
#call( $myLongWords.add("rhinoceros") )
...
You could even create an #add macro
#macro( add $array $value )#if( $array.add( $value ) )#**##end#end
and do
#add( $myLongWords "rhinoceros" )
That is the nice thing about macros...
Cheers,
Christoph
Andy Lee wrote:
> At 10:16 AM -0500 11/4/02, Kevin Baynes wrote:
[snip]
> #set( $myLongWords = [] )
> $myLongWords.add("rhinoceros")
> $myLongWords.add("callipygian")
> $myLongWords.add("lactovegetarian")
> $myLongWords.add("dodecahedron")
> $myLongWords.add("subliminable") ## political humor
> $myLongWords.add("Schwarzenegger")
> $myLongWords.add("0xDEADBEEF") ## geek humor
>
>
> Easier to read, easier to reorder, easier to comment items out. And
> notice that you can comment individual items in a readable way.
>
> But I don't mean to focus on hard-coding as the issue. The issue is
> calling non-getter methods at all. Regardless of hard-coding, *any*
> call to ArrayList.add(Object) or HashMap.put(Object,Object) has a return
> value, and I almost never want to display it.
>
> One could decide as a matter of policy to only call getter methods in
> templates. I would find this needlessly restrictive.
>
> --Andy
--
:) Christoph Reck
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: discarding method return values
Posted by Andy Lee <ag...@earthlink.net>.
At 10:03 PM -0500 11/4/02, Geir Magnusson Jr. wrote:
>On 11/4/02 5:13 PM, "Nathan Bubna" <na...@esha.com> wrote:
> > this has been discussed at least once before and IIRC there was no
> > objections. (cf. the "Whitespace, a break from the present line of debate"
> > thread some months back)
Interesting, thanks.
> > i think Geir has implemented multi-line #set() statements, but i
>do not know
>> the particulars of the implementation (i.e. multi-line string literals or
>> multi-line array literals or both) or remember if it ever got checked into
>> 1.4-dev.
>
>I'll punch them back in. They would be "multi-line anything that makes
>sense"
>
> :)
Cool, a feature that only works on things that make sense! This will
save me hours of debugging, as all my dumb mistakes will end up on
one line...
But seriously, I think this is a good thing.
--Andy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: discarding method return values
Posted by "Geir Magnusson Jr." <ge...@adeptra.com>.
On 11/4/02 5:13 PM, "Nathan Bubna" <na...@esha.com> wrote:
> Andy said:
> ...
>> Unless new information comes to light (like "They're planning to add
>> multi-line array literals to Velocity!"),
> ...
>
> this has been discussed at least once before and IIRC there was no
> objections. (cf. the "Whitespace, a break from the present line of debate"
> thread some months back)
>
> i think Geir has implemented multi-line #set() statements, but i do not know
> the particulars of the implementation (i.e. multi-line string literals or
> multi-line array literals or both) or remember if it ever got checked into
> 1.4-dev.
I'll punch them back in. They would be "multi-line anything that makes
sense"
:)
--
Geir Magnusson Jr.
geirm@adeptra.com +1-203-355-2219 (w)
Adeptra Inc. +1-203-247-1713 (m)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: discarding method return values
Posted by Nathan Bubna <na...@esha.com>.
Andy said:
...
> Unless new information comes to light (like "They're planning to add
> multi-line array literals to Velocity!"),
...
this has been discussed at least once before and IIRC there was no
objections. (cf. the "Whitespace, a break from the present line of debate"
thread some months back)
i think Geir has implemented multi-line #set() statements, but i do not know
the particulars of the implementation (i.e. multi-line string literals or
multi-line array literals or both) or remember if it ever got checked into
1.4-dev.
Nathan Bubna
nathan@esha.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: discarding method return values
Posted by Andy Lee <ag...@earthlink.net>.
At 2:28 PM -0500 11/4/02, Kevin Baynes wrote:
>Let me clarify: my question is "Why hardcode an array *in the
>Velocity Template*?".
Good, I figured that was really the more interesting question to you,
so I'm glad we got the other stuff out of the way.
I'm going to assume you are not opposed to the very existence of
array literals. The question seems to be, what should and shouldn't
be coded into array literals?
Unless new information comes to light (like "They're planning to add
multi-line array literals to Velocity!"), I am going to stand by my
argument that *if* you have a long array in your template, there are
good reasons to break it up into add() messages on multiple lines.
And that would be one example of calling a method in a template whose
return value you don't want to display.
>All your looping examples are perfectly correct, my focus is on what
>level you acquire the data and make decisions on it.
It depends what you call "data." I think it also depends on the
requirements and design of your application. At some point,
"cleanness" becomes "over-engineering."
>It seems cleaner to store data externally, in a properties file, in
>an XML file, in a database. I use XML files for this purpose, they
>are easy to read and change. I don't want any data hard-coded in my
>templates.
I don't think I'd make the statement so broadly. For any given app,
there are judgment calls to be made. After all, at some level,
*everything* in the template is "data."
Suppose you are writing a calendar application that needs to be
internationalized. If your design uses one central template for all
languages, then there should probably be Controller code to provide
the template with appropriate names for the months of the year.
*But* if your design uses a separate template for each country, and
the selection of the template itself is made by the Controller, then
I think it's okay to hard-code the month names into the template (or
put them in them in their own template to be #parsed). I think
creating a separate XML file or database table for this would be
over-engineering.
Another example. Suppose I have a Web page that lists my top 10
favorite stocks. Say this is a purely subjective thing; every day I
edit the list by hand, based on gut feel and brib^H^H^H^H reports
from publicly traded companies. I think it makes sense to have an
array at the top of my template like this (ignoring the fact that
this will print "true" ten times):
#set( $myFaves = [] )
$myFaves.add("AAPL")
$myFaves.add("XYZW")
$myFaves.add("VELO")
$myFaves.add("CITY")
## etc.
There's no advantage to putting this list in an XML file or database table.
*But* if I suddenly become the Martha Stewart of stock advice and my
"top 10" list is used in 137 worldwide media applications, then for
this Web page it makes sense to have the Controller get the list from
a central place and feed it to the template via the Velocity context.
*Or*, alternatively, my little .vm file could *be* the central place
everybody else gets the list from, in which case I'm back to
hand-editing the file again.
--Andy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: discarding method return values
Posted by Kevin Baynes <kb...@seagullsw.com>.
> >Not to be contentious, merely friendly discussion here. :-)
>
> Yup, no worries.
Good. :-)
>
> > Once you are in the Template, what is the difference between
> >writing the above list and calling #foreach, or simply writing:
> ><select name="myWordRoots">
> > <option value="Rhinocerotidae">Rhinoceros
> > <option value="kallipugos">callipygian
> > ....
> ></select>
>
> I interpret this question as: "Why use an array at all?" You guessed
> part of my answer below, which is that I might want to use the array
> in more than one place. Or I might want to do something with the
> array index, like:
Let me clarify: my question is "Why hardcode an array *in the Velocity
Template*?". All your looping examples are perfectly correct, my focus is on
what level you acquire the data and make decisions on it. I store data in a
file or a database, then pull the data into my controller, make decisions on
it and place the finished array (or Object) into the Velocity context.
I see "if sunday then exclude lactovegetarian" as a business logic /
Controller decision, and "if odd row, then gray background" as a View
decision.
Also, IMHO storing Data in a Template is a 'Bad Thing' - (no offense). It
seems cleaner to store data externally, in a properties file, in an XML
file, in a database. I use XML files for this purpose, they are easy to read
and change. I don't want any data hard-coded in my templates.
Again, this is an interesting applied MVC theory discussion to me, I'm not
trying to be contentious.
~k
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: discarding method return values
Posted by Andy Lee <ag...@earthlink.net>.
At 11:57 AM -0500 11/4/02, Kevin Baynes wrote:
> > #set( $myLongWords = [] )
> > $myLongWords.add("rhinoceros")
> > $myLongWords.add("callipygian")
> > $myLongWords.add("lactovegetarian")
> > $myLongWords.add("dodecahedron")
>> $myLongWords.add("subliminable") ## political humor
>> $myLongWords.add("Schwarzenegger")
>> $myLongWords.add("0xDEADBEEF") ## geek humor
>
>Not to be contentious, merely friendly discussion here. :-)
Yup, no worries.
> Once you are in the Template, what is the difference between
>writing the above list and calling #foreach, or simply writing:
><select name="myWordRoots">
> <option value="Rhinocerotidae">Rhinoceros
> <option value="kallipugos">callipygian
> ....
></select>
I interpret this question as: "Why use an array at all?" You guessed
part of my answer below, which is that I might want to use the array
in more than one place. Or I might want to do something with the
array index, like:
<select name="myWordRoots">
#set( $i = 0 )
#foreach( $word in $myLongWords )
<option value="$i">$word</option>
#set( $i = $i + 1 )
#end
</select>
Another part of my answer has to do with personal preferences I have
about coding. One is that I like to keep the code for an HTML
element small if possible. In this case I have an opportunity to
keep the distance between <select> and </select> quite small,
regardless of the number of <option> elements in between.
Imagine if this were a <table> instead of a popup list, and the table
has multiple columns and <font> tags and bits of stuff like...
bgcolor="#if( $evenRow )#FFFFFF#else#DDDDDD#end"
...all over the place. Looping through an array starts to look a lot
more attractive, especially when a designer decides #DDDDDD should
really be #CCCCCC.
>(Truly inquisitive tone follows)
>Why is it easier to reorder the method calls above than to reorder the HTML?
It's not, at least in the simple case of just <option> elements within a menu.
It *is* easier to reorder the method calls than to reorder items in a
long array literal like
#set( $myLongWords = [ "rhinoceros", "callipygian",
"lactovegetarian", "dodecahedron", "subliminable", "Schwarzenegger",
"0xDEADBEEF" ] )
You don't have to worry about commas, and if you use CVS and someone
does a diff, it's easier to see what changed than if you check in:
#set( $myLongWords = [ "rhinoceros", "callipygian", "dodecahedron",
"lactovegetarian", "subliminable", "Schwarzenegger", "0xDEADBEEF" ] )
Plus, again, with the separate lines you can comment each item individually:
$myLongWords.add("lactovegetarian") ## except Sundays
>Why would you need to build the list using Java objects in the Template?
I wouldn't need to, but I might prefer to, for the reasons above. I
think it makes my job easier and less error-prone.
>The only reason I can think of is if you repeated the same list a
>number of times, having the same popup menu in numerous places... in
>which case you could do:
>
><select>
>#parse("myLongWordOptions.vm")
></select>
I might want to reuse the array for other purposes.
Maybe in addition to the popup menu, I'm using the array to generate
a table of contents, and I want to use the names both to generate
hyperlinks and to create anchor links farther down the page:
#foreach( $word in $myLongWords )
<a href="#$word">$word</a>
#end
## ...
#foreach( $word in $myLongWords )
<hr>
<h2><a name="$word">$word</a></h2>
<p>
$myLongWordDefinitions.get($word)
#end
--Andy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: discarding method return values
Posted by Kevin Baynes <kb...@seagullsw.com>.
> One example of hard-coding an array would be to create a popup menu.
> The labels in the menu are View objects. I might want the array
> contents to depend on run-time conditions.
>
> Or I might simply want to get around the fact that literals in
> Velocity can't be multi-line. Instead of one long array assignment,
> I might prefer:
>
>
> #set( $myLongWords = [] )
> $myLongWords.add("rhinoceros")
> $myLongWords.add("callipygian")
> $myLongWords.add("lactovegetarian")
> $myLongWords.add("dodecahedron")
> $myLongWords.add("subliminable") ## political humor
> $myLongWords.add("Schwarzenegger")
> $myLongWords.add("0xDEADBEEF") ## geek humor
Not to be contentious, merely friendly discussion here. :-) Once you are in
the Template, what is the difference between writing the above list and
calling #foreach, or simply writing:
<select name="myWordRoots">
<option value="Rhinocerotidae">Rhinoceros
<option value="kallipugos">callipygian
....
</select>
(Truly inquisitive tone follows)
Why is it easier to reorder the method calls above than to reorder the HTML?
Why would you need to build the list using Java objects in the Template?
The only reason I can think of is if you repeated the same list a number of
times, having the same popup menu in numerous places... in which case you
could do:
<select>
#parse("myLongWordOptions.vm")
</select>
or
#set($excludeActionHeroes = true)
<select>
#parse("myLongWordOptions.vm")
</select>
...myLongWordOptions.vm...
#if(!$excludeGeometrcs)<option>dodecahedron#end
#if(!$excludeActionHeroes)<option>Schwarzenegger#end
...
I have not yet found a reason to call any method on an Object in the
Template where I did not want to see it's results displayed: that's the job
of the Controller.
Just because I can't think of it doesn't mean there isn't one. :-)
Respectfully,
~Kevin
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: discarding method return values
Posted by Andy Lee <ag...@earthlink.net>.
At 10:16 AM -0500 11/4/02, Kevin Baynes wrote:
> > At 9:26 AM -0500 11/4/02, bob mcwhirter wrote:
>> >Sorry for being pedantic here, but if you're calling a method and
>> >ignore its return value in a template, then you're just wanting the
>> >side-effects of the method call? I'd consider that to probably be a
>> >Bad Programming Practice.
>>
>> Arguably so, but IMO it depends on the situation. In the
>> examples I gave...
>>
>> $myArray.add("x")
>>
>> $myHashMap.put("name", "bob")
>>
>> $myStringBuffer.append("...")
>>
> > ...I think it's reasonable to ignore the return values.
>
>I think Bob's point is that the template is the 'View', if you are calling
>methods which you don't want to 'View' then they should be in the
>'Controller'.
If that was Bob's point, I respectfully disagree. I think there are
many cases in a Velocity template where it's okay to call a method
only for its side effects.
> Why would you ever need to hardcode an array/hashmap in the
>template and then iterate over it?
>
One example of hard-coding an array would be to create a popup menu.
The labels in the menu are View objects. I might want the array
contents to depend on run-time conditions.
Or I might simply want to get around the fact that literals in
Velocity can't be multi-line. Instead of one long array assignment,
I might prefer:
#set( $myLongWords = [] )
$myLongWords.add("rhinoceros")
$myLongWords.add("callipygian")
$myLongWords.add("lactovegetarian")
$myLongWords.add("dodecahedron")
$myLongWords.add("subliminable") ## political humor
$myLongWords.add("Schwarzenegger")
$myLongWords.add("0xDEADBEEF") ## geek humor
Easier to read, easier to reorder, easier to comment items out. And
notice that you can comment individual items in a readable way.
But I don't mean to focus on hard-coding as the issue. The issue is
calling non-getter methods at all. Regardless of hard-coding, *any*
call to ArrayList.add(Object) or HashMap.put(Object,Object) has a
return value, and I almost never want to display it.
One could decide as a matter of policy to only call getter methods in
templates. I would find this needlessly restrictive.
--Andy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: discarding method return values
Posted by Kevin Baynes <kb...@seagullsw.com>.
> At 9:26 AM -0500 11/4/02, bob mcwhirter wrote:
> >Sorry for being pedantic here, but if you're calling a method and
> >ignore its return value in a template, then you're just wanting the
> >side-effects of the method call? I'd consider that to probably be a
> >Bad Programming Practice.
>
> Arguably so, but IMO it depends on the situation. In the
> examples I gave...
>
> $myArray.add("x")
>
> $myHashMap.put("name", "bob")
>
> $myStringBuffer.append("...")
>
> ...I think it's reasonable to ignore the return values.
I think Bob's point is that the template is the 'View', if you are calling
methods which you don't want to 'View' then they should be in the
'Controller'. Why would you ever need to hardcode an array/hashmap in the
template and then iterate over it?
~k
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: discarding method return values
Posted by Andy Lee <ag...@earthlink.net>.
At 9:26 AM -0500 11/4/02, bob mcwhirter wrote:
>Sorry for being pedantic here, but if you're calling a method and
>ignore its return value in a template, then you're just wanting the
>side-effects of the method call? I'd consider that to probably be a
>Bad Programming Practice.
Arguably so, but IMO it depends on the situation. In the examples I gave...
$myArray.add("x")
$myHashMap.put("name", "bob")
$myStringBuffer.append("...")
...I think it's reasonable to ignore the return values. In these
cases, the return values are provided as a redundant convenience --
for example, to chain append() messages -- not because their values
absolutely must be dealt with.
In C (when I'm being meticulous), I explicitly cast function calls to
(void) when I'm ignoring return values. Can't do this in Java. The
nearest thing would be:
ArrayList myArray = new ArrayList();
boolean ignore;
ignore = myArray.add("a");
ignore = myArray.add("b");
ignore = myArray.add("c");
But I don't like variables that are meant to be ignored. A matter of
taste, perhaps.
>Though, cheap and easy is to stick it inside HTML comments, if
>you're playing with HTML. <!-- foo.getBar() -->.
>
>Velocity will ignore the HTML comment gleefully, and they'll
>prevent the return from being seen.
>
Another handy tip, thanks.
--Andy
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: discarding method return values
Posted by bob mcwhirter <bo...@werken.com>.
On Mon, 4 Nov 2002, bob mcwhirter wrote:
> That logic is probably better-suited for the Controller end of things,
> and in the View.
grr... can't type.
That logic is probably better-suited for the Controller end of things,
and *NOT* in the View.
-bob
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: controller logic (was: discarding method return..)
Posted by Tim Colson <tc...@cisco.com>.
Bob -
> Sorry for being pedantic here, but if you're calling a method and
> ignore its return value in a template, then you're just wanting
> the side-effects of the method call? I'd consider that to probably
> be a Bad Programming Practice. That logic is probably better-suited
> for the Controller end of things, and [not] in the View.
Certainly a good point, thanks for correcting me.
Not that anyone cares, but when I wrap stuff, it's usually to prevent an
accidental method access like $myhashmap.clear(), or perhaps
myAppScopeHash.put("FOO", "BAR") or other nasties in the View. (I did
say I'm paranoid, didn't I? ;-)
I take a simpleton approach to the templates - 99% of mine consist of
$thing, #foreach ($thing in $LIST_OF_THINGS), #if ($thingIsTrue), #macro
(coolthing $thing) - i.e. mostly read-only operations because the
controller code has done all the heavy-lifting.
Say - off this topic, but wouldn't it be cool if a template editor
application could do inline introspection?
Ex. type "$" and up pops a list of items in the context, select
"myhashmap" from that list, type "." and up pops a list of possible
methods & keys?
Jumping way way way ahead...if that existed, then for my stuff, I'd want
to avoid placing a full blown HashMap into the context, and instead use
a simpler wrapper that only had...oh... get() and maybe keyset()
available. Almost brings to mind similar aspects of 'security by
obscurity' problems. :-)
Cheers!
Tim
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: discarding method return values
Posted by bob mcwhirter <bo...@werken.com>.
Sorry for being pedantic here, but if you're calling a method and
ignore its return value in a template, then you're just wanting
the side-effects of the method call? I'd consider that to probably
be a Bad Programming Practice. That logic is probably better-suited
for the Controller end of things, and in the View.
Though, cheap and easy is to stick it inside HTML comments, if
you're playing with HTML. <!-- foo.getBar() -->.
Velocity will ignore the HTML comment gleefully, and they'll
prevent the return from being seen.
-bob
On Mon, 4 Nov 2002, Tim Colson wrote:
> It's a workaround, which of course means 'more work' for the developer,
> but sometimes I've personally used wrapper classes around even hashes so
> that I can specifically make a subset of methods available. Yeah, I'm
> paranoid. <grin>
>
> > I often want to discard the return values of methods.
>
> Perhaps this workaround of creating a wrapper with a custom method
> signature like:
> public void add(Object obj), which delegates to 'boolean add()' and
> disposes of the unwanted return would help clean up the template, and at
> the same time keep Velocity dirt simple? :-)
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: discarding method return values
Posted by Tim Colson <tc...@cisco.com>.
Andy -
It's a workaround, which of course means 'more work' for the developer,
but sometimes I've personally used wrapper classes around even hashes so
that I can specifically make a subset of methods available. Yeah, I'm
paranoid. <grin>
> I often want to discard the return values of methods.
Perhaps this workaround of creating a wrapper with a custom method
signature like:
public void add(Object obj), which delegates to 'boolean add()' and
disposes of the unwanted return would help clean up the template, and at
the same time keep Velocity dirt simple? :-)
Cheers,
Tim
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>