You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by Gernot Hueller <g....@gmx.at> on 2003/11/25 11:58:13 UTC

Support for array.length ?

Dear all,

I know velocity can only introspect Methods, not member variables, but
perhaps you could make an exception for arrays?
Arrays are basically suported with foreach iteration.
Now it would be great if I could also say "$myarray.length items displayed".
Is this possible somehow now?
If not, does someone agree this could be implemented?

I think .length support should be possible only IF the passed variable is an
array, and for nothing else.

(I wasn't sure if this is a velocity-user or velocity-dev question so I sent
to both. Sorry if anyone is bothered)

-- 
GMX Weihnachts-Special: Seychellen-Traumreise zu gewinnen!

Rentier entlaufen. Finden Sie Rudolph! Als Belohnung winken
tolle Preise. http://www.gmx.net/de/cgi/specialmail/

+++ GMX - die erste Adresse f�r Mail, Message, More! +++


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org


Re: Support for array.length ?

Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Dec 11, 2003, at 3:20 PM, Ilkka Priha wrote:

> J. B. Rainsberger wrote:
>
>> Geir Magnusson Jr wrote:
>> <snip />
>>> I then thought about treating an Object[] as a collection as far as 
>>> we could, returning things like size(), iterator(), etc where 
>>> possible. This doesn't seem to be too insane, but also is, when 
>>> caught by surprise by the idea,  more magic yecchy behavior.  
>>> However, if you aren't caught by surprise, and think about it, it 
>>> isn't all bad.
>> It's a collection -- just a fixed-size one. Why /not/ treat it like a 
>> collection? It's not Velocity's fault that Java couldn't escape its 
>> heritage.
>
>
> On the other hand, it's quite easy to wrap arrays with
>
> java.util.Arrays.asList(Object[] array)
>
> at the time when arrays needing collection support are put into the 
> context without requiring Velocity to do it. Primitive arrays require 
> some more work, though.

That's true too - you could have an impl of Context that has clever 
wrapper support for put() so it would happen automatically.

Fun problem :)

geir

>
> -- Ilkka
>
>
>
> ---------------------------------------------------------------------
> 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: Support for array.length ?

Posted by Ilkka Priha <im...@surfeu.fi>.
J. B. Rainsberger wrote:

> Geir Magnusson Jr wrote:
> 
> <snip />
> 
>> I then thought about treating an Object[] as a collection as far as we 
>> could, returning things like size(), iterator(), etc where possible. 
>> This doesn't seem to be too insane, but also is, when caught by 
>> surprise by the idea,  more magic yecchy behavior.  However, if you 
>> aren't caught by surprise, and think about it, it isn't all bad.
> 
> 
> It's a collection -- just a fixed-size one. Why /not/ treat it like a 
> collection? It's not Velocity's fault that Java couldn't escape its 
> heritage.


On the other hand, it's quite easy to wrap arrays with

java.util.Arrays.asList(Object[] array)

at the time when arrays needing collection support are put into the 
context without requiring Velocity to do it. Primitive arrays require 
some more work, though.

-- Ilkka



---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Re: Support for array.length ?

Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Dec 11, 2003, at 2:09 PM, J. B. Rainsberger wrote:

> Geir Magnusson Jr wrote:
>
> <snip />
>
>> I then thought about treating an Object[] as a collection as far as 
>> we could, returning things like size(), iterator(), etc where 
>> possible. This doesn't seem to be too insane, but also is, when 
>> caught by surprise by the idea,  more magic yecchy behavior.  
>> However, if you aren't caught by surprise, and think about it, it 
>> isn't all bad.
>
> It's a collection -- just a fixed-size one. Why /not/ treat it like a 
> collection? It's not Velocity's fault that Java couldn't escape its 
> heritage.

Right - exactly, although I don't think it's a thing that needs to be 
escaped...  I like having primitive things when perf counts.

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: Support for array.length ?

Posted by Dave Newton <da...@solaraccess.com>.
> On Dec 29, 2003, at 9:47 PM, Nathan Bubna wrote:
> I just started w/ $, but you're right - it's not a reference.  It's not 
> really a directive either.
> 
> @isEmpty($foo)
> %isEmpty($foo)
> &isEmpty($foo)

*shudder*

I hate magic characters.

And it is _sort_ of a reference; a reference to magic Velocity internals.

> #set($res = &isEmpty($foo))

There's still some punctuation we haven't used yet, danggit.

Must... use... all... ASCII... characters...

;)

Dave



---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Re: Tools Nightly Snapshots?

Posted by Nathan Bubna <na...@esha.com>.
Tim Colson said:
> Say gang - the the Nightly snapshot link here seems to send folks to old
> and zero-byte stuff: 
> http://jakarta.apache.org/velocity/tools/index.html#Download

hmm.  apparently the scripts that were making those builds are no longer.

it looks like a number of other projects have "snapshots" being built here:
http://cvs.apache.org/snapshots/

but i have no idea how to get our stuff include there.  anyone else know?

Nathan Bubna
nathan@esha.com

---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org


Tools Nightly Snapshots?

Posted by Tim Colson <tc...@cisco.com>.
Say gang - the the Nightly snapshot link here seems to send folks to old
and zero-byte stuff: 
http://jakarta.apache.org/velocity/tools/index.html#Download


Cheers,
Timo


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org


Re: Support for array.length ?

Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr said:
> On Dec 30, 2003, at 2:57 PM, Nathan Bubna wrote:
...
> >  i just tire of people asking for
> > $array.length and
> > think a little $array.size() magic wouldn't hurt. :)
>
> An alternative, which is breaking with the past, is to allow access to
> public fields, and then fake it for length because people think that's
> a field anyway.
>
> The only problem I have with that is it's piss-poor programming
> practice.

yeah i have that problem with it too.  add that to my problem with the
inconsistent access to array data and List data. :)

> > ...
> >>> discourage developers from passing arrays in the context.
> >>
> >> Yes!
> >
> > this is a better solution than any @isEmpty($array) stuff.  :)
>
> Which is really no more than an context-less tool mechanism.  :)

yep.  and would therefore be a new paradigm with a new syntax.  :)

and around we go again... :)

seriously, i think we've pretty much exhausted the subject at this point.

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: Support for array.length ?

Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Dec 30, 2003, at 2:57 PM, Nathan Bubna wrote:

> Geir Magnusson Jr said:
>> On Dec 30, 2003, at 2:02 PM, Andy Lee wrote:
>>> Nathan Bubna wrote:
>>>
>>>> blech.  my vote is still for
>>>>
>>>> #set( $bar = $array.isEmpty() )
>>>>
>>> Mine too.  If we want to hide the differences between arrays and 
>>> Lists
>>> from the designer, I think the VTL specification should define a
>>> subset of the List interface methods that magically work on arrays.
>>> Obviously these would include isEmpty() and size(); I'm not sure
>>> offhand what else.
>>
>> I actually think the model should do it.  if the designer is expecting
>> something on which they can do 'size()' it's not VTL's problem.
>
> agreed.  and with that, i'll admit that i don't ever put arrays in the 
> context
> myself, nor do i intend to. i just tire of people asking for 
> $array.length and
> think a little $array.size() magic wouldn't hurt. :)
>

An alternative, which is breaking with the past, is to allow access to 
public fields, and then fake it for length because people think that's 
a field anyway.

The only problem I have with that is it's piss-poor programming 
practice.

> ...
>>> To me, the really painful part of making arrays work like Lists is
>>> their fixed length.  It sucks that a designer would need to know that
>>> a collection object might not be growable.  I can't think of a
>>> solution for this.  The nearest I can think of is to discourage
>>> developers from passing arrays in the context.
>>
>> Yes!
>
> this is a better solution than any @isEmpty($array) stuff.  :)

Which is really no more than an context-less tool mechanism.  :)

>
> 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: Support for array.length ?

Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr said:
> On Dec 30, 2003, at 2:02 PM, Andy Lee wrote:
> > Nathan Bubna wrote:
> >
> >> blech.  my vote is still for
> >>
> >> #set( $bar = $array.isEmpty() )
> >>
> > Mine too.  If we want to hide the differences between arrays and Lists
> > from the designer, I think the VTL specification should define a
> > subset of the List interface methods that magically work on arrays.
> > Obviously these would include isEmpty() and size(); I'm not sure
> > offhand what else.
>
> I actually think the model should do it.  if the designer is expecting
> something on which they can do 'size()' it's not VTL's problem.

agreed.  and with that, i'll admit that i don't ever put arrays in the context
myself, nor do i intend to. i just tire of people asking for $array.length and
think a little $array.size() magic wouldn't hurt. :)

...
> > To me, the really painful part of making arrays work like Lists is
> > their fixed length.  It sucks that a designer would need to know that
> > a collection object might not be growable.  I can't think of a
> > solution for this.  The nearest I can think of is to discourage
> > developers from passing arrays in the context.
>
> Yes!

this is a better solution than any @isEmpty($array) stuff.  :)

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: Support for array.length ?

Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Dec 30, 2003, at 2:02 PM, Andy Lee wrote:

> Nathan Bubna wrote:
>
>> blech.  my vote is still for
>>
>> #set( $bar = $array.isEmpty() )
>>
>>
>
> Mine too.  If we want to hide the differences between arrays and Lists 
> from the designer, I think the VTL specification should define a 
> subset of the List interface methods that magically work on arrays.  
> Obviously these would include isEmpty() and size(); I'm not sure 
> offhand what else.

I actually think the model should do it.  if the designer is expecting 
something on which they can do 'size()' it's not VTL's problem.

>
> My main reason for this preference is to keep new syntax to an 
> absolute minimum, preferring where possible to extend existing syntax 
> to do the convenient thing.
>
> Another (small) benefit of using the isEmpty() method notation is that 
> the developer could change $array to an object that is *neither* an 
> array nor a List, but does respond to isEmpty(), and the template will 
> still work.

I think the contract should be set by the programmer - he/she says 
"here's what you are going to find in the context...."

>
> To me, the really painful part of making arrays work like Lists is 
> their fixed length.  It sucks that a designer would need to know that 
> a collection object might not be growable.  I can't think of a 
> solution for this.  The nearest I can think of is to discourage 
> developers from passing arrays in the context.

Yes!

geir

>
> --Andy
>
>
> ---------------------------------------------------------------------
> 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: Support for array.length ?

Posted by Nathan Bubna <na...@esha.com>.
Andy Lee said:
> Nathan Bubna wrote:
> >blech.  my vote is still for
> >
> >#set( $bar = $array.isEmpty() )
>
> Mine too.  If we want to hide the differences between arrays and Lists
> from the designer, I think the VTL specification should define a subset
> of the List interface methods that magically work on arrays.  Obviously
> these would include isEmpty() and size(); I'm not sure offhand what else.

$array.get($i)

> My main reason for this preference is to keep new syntax to an absolute
> minimum, preferring where possible to extend existing syntax to do the
> convenient thing.
...
> To me, the really painful part of making arrays work like Lists is their
> fixed length.  It sucks that a designer would need to know that a
> collection object might not be growable.  I can't think of a solution
> for this.  The nearest I can think of is to discourage developers from
> passing arrays in the context.

IMHO, this is a non-issue.  same issue can follow from putting unmodifiable
Lists in the context (something i'm a believer in).  i've never been keen on
the idea of modifying objects put in a template.  accessing is critical, but i
see little value and much danger in modifying.  (note that i feel differently
about maps, lists, strings, and numbers that are instantiated in the the
template.)

i may not be an MVC purist, but i still think it's a very good set of
guidelines.

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: Support for array.length ?

Posted by Andy Lee <ag...@earthlink.net>.
Nathan Bubna wrote:

>blech.  my vote is still for
>
>#set( $bar = $array.isEmpty() )
>
>  
>

Mine too.  If we want to hide the differences between arrays and Lists 
from the designer, I think the VTL specification should define a subset 
of the List interface methods that magically work on arrays.  Obviously 
these would include isEmpty() and size(); I'm not sure offhand what else.

My main reason for this preference is to keep new syntax to an absolute 
minimum, preferring where possible to extend existing syntax to do the 
convenient thing.

Another (small) benefit of using the isEmpty() method notation is that 
the developer could change $array to an object that is *neither* an 
array nor a List, but does respond to isEmpty(), and the template will 
still work.

To me, the really painful part of making arrays work like Lists is their 
fixed length.  It sucks that a designer would need to know that a 
collection object might not be growable.  I can't think of a solution 
for this.  The nearest I can think of is to discourage developers from 
passing arrays in the context.

--Andy


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


compile errors with CVS head

Posted by "Charles N. Harvey III" <ch...@alloy.com>.
Hello out there.
Now, I'm sure that I am doing something wrong here, but when I run
"maven" from the command line on the CVS head of "jakarta-velocity"
I get:


[javac] Compiling 4 source files to /home/charvey/projects/jakarta-velocity/target/classes
~/projects/jakarta-velocity/src/java/org/apache/velocity/test/VelocityServletTest.java:170:
    org.apache.velocity.test.VelocityServletTest.MockServletContext is not abstract and does
    not override abstract method getResourcePaths(java.lang.String) in javax.servlet.ServletContext
       static class MockServletContext implements ServletContext
              ^

/home/charvey/projects/jakarta-velocity/src/java/org/apache/velocity/test/VelocityServletTest.java:285:
    org.apache.velocity.test.VelocityServletTest.MockHttpServletResponse is not abstract and does
    not override abstract method resetBuffer() in javax.servlet.ServletResponse
       static class MockHttpServletResponse implements HttpServletResponse
              ^


Does this happen to anyone else?  Am I missing something?

Oh yeah, and is there any chance that the velocity-dep-1.4.rc1.jar could be
put up as a nightly or release build?


Thanks.


Charlie

---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Re: missing mesgs?

Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Dec 30, 2003, at 2:48 PM, Tim Colson wrote:

>> whoa.  I missed Tim's message.  Did everyone get it?
>
> I have personally received 100% of my own drivel. :-)
>
> I did notice earlier today a reply to Peter by Nathan (Heck, I even
> replied to Peter)... but I don't recall seeing the original Peter post.
> So either it was private, or the email list gremlins are active.

I got yours eventually.  A long time later.  It's very possible that my 
cable provider is having problems (again) w/ mail.  I need to switch my 
subscriptions...

>
> -Timo
>
>
> ---------------------------------------------------------------------
> 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: missing mesgs?

Posted by Tim Colson <tc...@cisco.com>.
> whoa.  I missed Tim's message.  Did everyone get it?

I have personally received 100% of my own drivel. :-)

I did notice earlier today a reply to Peter by Nathan (Heck, I even
replied to Peter)... but I don't recall seeing the original Peter post.
So either it was private, or the email list gremlins are active.

-Timo


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Re: Support for array.length ?

Posted by Geir Magnusson Jr <ge...@4quarters.com>.
whoa.  I missed Tim's message.  Did everyone get it?

On Dec 30, 2003, at 12:17 PM, Nathan Bubna wrote:

> Tim Colson said:
>>> #set( $bar = $array.isEmpty() )
>>> just a little magic.  :)
>>> keeps things simple and pretty for designers.
>>> no new paradigm, no new syntax.
>>
>> Or...
>>
>>   context.put("EMPTY", new Boolean(array.length == 0));
>>
>>   #if ($EMPTY) #end
>>
>> ZERO magic. :-)
>> Simpler and pretty for designers.
>> Absolutely no new paradigm, no new syntax.
>
> yeah, and a PITA for developers.  :)
>
> some of us like to occasionally break MVC rules! we're not 
> StringTemplate
> conservatives nor PHP liberals.  we're Velocity moderates.
>
> sorry, election year coming up; it rubs off.  ;)
>
> 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: Support for array.length ?

Posted by Andy Lee <ag...@earthlink.net>.
Tim Colson wrote:

>>This doesn't help if:
>>* the collection in question isn't an array, and might change length 
>>during the rendering of the template;
>>    
>>
>
>I'm simple-minded, the proposal is aimed at giving Arrays special powers
>that Collections have - namely isEmpty(). Adding a context var $EMPTY
>allows any boolean condition, from any object, not just arrays.
>
>context.put("EMPTY", new Boolean(MyObjectThingy.isEmpty() ) );
>  
>

You missed my point.  If MyObjectThingy is a List, and something in the 
template changes it from empty to non-empty or vice versa, $EMPTY will 
have a bogus value.

>>* the array is created *in* the template, and is not 
>>accessible to the  (Java) developer; or
>>    
>>
>Good point, but not one that bothers me personally.
>  
>

I'm guessing it doesn't bother you because of the conventions and habits 
you choose to adopt.  Which is probably a good thing!

>>* you have a variable in the template that may refer to array 
>>X, Set Y, or ArrayList Z, and you won't know which until the template 
>>is rendered.
>>    
>>
>Hmm, ok. (I can't think of a use case where a Developer wouldn't know
>what she/he was putting into the context.
>

Again, you missed my point (and/or I made it poorly).  I meant that a 
given variable name can refer to different objects at different points 
in the rendering of the template.

To illustrate another way, suppose you have a macro that takes a 
collection (with a lower-case "c") as an argument, and needs to figure 
out whether the collection is empty.  The macro can't know in advance 
whether it will be passed an array or a List.  And in the case of an 
array, the macro can't know in advance whether it needs to check 
$EMPTYONE or $EMPTYTWO, or whether the array even has a corresponding 
$EMPTYx.

One possible answer to this is, "It's bad practice to write a macro 
whose argument can be either an array or a List."

> But I tend to use Lists, so
>this whole array thing doesn't bother me much. <grin>)
>  
>

Probably a wise approach!  It's nice when a language can give you stuff 
for free, but sometimes you have to rely on conventions and habits.  By 
sticking with Lists, you don't run into the macro problem I just described.

>>$myArrayThree for which there is no $myArrayThreeIsEmpty; the 
>>designer  would have to "magically" know that.
>>    
>>
>I'm going to argue only one part of this...the magic I speak of is:
> 
>$array.method_that_an_array_does_not_do_so_this_is_Velocity_magic
>
>What you speak of is just my Developer documentation:
>"Hey Designer buddy, there will be two lists called $list_of_stuff,
>$list_of_details, and if you want to know if either one is empty, there
>will be true/false values in $stuff_is_empty and $details_are_empty."
>
>Where list_of_stuff is an array, and list_of_details is an ArrayList -
>but hey my Designer doesn't know or care. ;-)
>  
>

The distinction you make is exactly right.  My quibble is with the word 
"just."  As the number of arrays grows, the documentation starts to have 
a lot of copied-and-pasted text.  To the extent we can glom arrays and 
Collections conceptually into one list type, the documentation becomes 
simpler.  You could just say "$foo is one of these list things," and the 
designer would know that isEmpty() will work.

--Andy


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


RE: Support for array.length ?

Posted by Tim Colson <tc...@cisco.com>.
> >  context.put("EMPTY", new Boolean(array.length == 0));
> >  #if ($EMPTY) #end

> This doesn't help if:
> * the collection in question isn't an array, and might change length 
> during the rendering of the template;

I'm simple-minded, the proposal is aimed at giving Arrays special powers
that Collections have - namely isEmpty(). Adding a context var $EMPTY
allows any boolean condition, from any object, not just arrays.

context.put("EMPTY", new Boolean(MyObjectThingy.isEmpty() ) );

> * the array is created *in* the template, and is not 
> accessible to the  (Java) developer; or
Good point, but not one that bothers me personally.
 
> * you have a variable in the template that may refer to array 
> X, Set Y, or ArrayList Z, and you won't know which until the template 
> is rendered.
Hmm, ok. (I can't think of a use case where a Developer wouldn't know
what she/he was putting into the context. But I tend to use Lists, so
this whole array thing doesn't bother me much. <grin>)


> $myArrayThree for which there is no $myArrayThreeIsEmpty; the 
> designer  would have to "magically" know that.
I'm going to argue only one part of this...the magic I speak of is:
 
$array.method_that_an_array_does_not_do_so_this_is_Velocity_magic

What you speak of is just my Developer documentation:
"Hey Designer buddy, there will be two lists called $list_of_stuff,
$list_of_details, and if you want to know if either one is empty, there
will be true/false values in $stuff_is_empty and $details_are_empty."

Where list_of_stuff is an array, and list_of_details is an ArrayList -
but hey my Designer doesn't know or care. ;-)

Cheers,
Timo "I'm not as lazy as Nathan" Colson <grin>





---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Re: Support for array.length ?

Posted by Andy Lee <ag...@earthlink.net>.
Tim Colson said:

>  context.put("EMPTY", new Boolean(array.length == 0));
>
>  #if ($EMPTY) #end
>
>ZERO magic. 
>  
>

This doesn't help if:

* the collection in question isn't an array, and might change length 
during the rendering of the template;

* the array is created *in* the template, and is not accessible to the 
(Java) developer; or

* you have a variable in the template that may refer to array X, Set Y, 
or ArrayList Z, and you won't know which until the template is rendered.

Furthermore, the developer has to communicate additional special 
knowledge to the designer.  Not only does the context contain variables 
$myArrayOne and $myArrayTwo, it also contains variables 
$myArrayOneIsEmpty and $myArrayTwoIsEmpty.  Rather than a consistent 
syntax for determining the lengths of collections, the designer has to 
learn the developer's naming convention for the "fooIsEmpty" variables 
-- assuming there *is* a consistently applied convention.

I would actually categorize this type of specialized knowledge as 
"magic" in the sense of "magic numbers."  For example, there might be a 
$myArrayThree for which there is no $myArrayThreeIsEmpty; the designer 
would have to "magically" know that.

--Andy


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Re: Support for array.length ?

Posted by Serge Knystautas <se...@lokitech.com>.
Dave Newton wrote:
>>>My designer says "I'd rather use isEmpty because that would always work
> and
>>>I wouldn't have to rely on you [me, Dave] to remember to put an EMPTY in
> the
>>>context, because you're a dork."
>>+1
> 
> Hey, wait a minute... I'm only partially sure you're +1ing the isEmpty and
> not the dork part...

I meant I'm agreeing that I've had the same comment from designers (that 
they prefer isEmpty, and that I'm a dork.)

-- 
Serge Knystautas
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: Support for array.length ?

Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Dec 30, 2003, at 2:48 PM, Dave Newton wrote:

> From: "Serge Knystautas" <se...@lokitech.com>
>> Dave Newton wrote:
>>> My designer says "I'd rather use isEmpty because that would always 
>>> work
> and
>>> I wouldn't have to rely on you [me, Dave] to remember to put an 
>>> EMPTY in
> the
>>> context, because you're a dork."
>>
>> +1
>
> Hey, wait a minute... I'm only partially sure you're +1ing the isEmpty 
> and
> not the dork part...

I was certain it was for the dork part :)

>
> Dave
>
>
>
> ---------------------------------------------------------------------
> 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: Support for array.length ?

Posted by Dave Newton <da...@solaraccess.com>.
From: "Serge Knystautas" <se...@lokitech.com>
> Dave Newton wrote:
> > My designer says "I'd rather use isEmpty because that would always work
and
> > I wouldn't have to rely on you [me, Dave] to remember to put an EMPTY in
the
> > context, because you're a dork."
>
> +1

Hey, wait a minute... I'm only partially sure you're +1ing the isEmpty and
not the dork part...

Dave



---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Re: Support for array.length ?

Posted by Serge Knystautas <se...@lokitech.com>.
Dave Newton wrote:
> My designer says "I'd rather use isEmpty because that would always work and
> I wouldn't have to rely on you [me, Dave] to remember to put an EMPTY in the
> context, because you're a dork."

+1

-- 
Serge Knystautas
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: Support for array.length ?

Posted by Tim Colson <tc...@cisco.com>.
> I made him learn it.   :D
LOL :-)

> I think null, but that's just me--to me "empty" implies "that 
> doesn't really exist," whereas zero exists and would be a separate
test.

Yep, that's my point. Opinions on isEmpty will vary, so it feels weird
that Velocity would make the magic isEmpty() decision. 

And it gets uglier to define if the underlying type is not an
array/list/set:

#if ( $GAS.levels.isEmpty() ) You need gas, son. #end
- where $GAS.levels returns a floating point number

Cheers,
Timo




---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Re: Support for array.length ?

Posted by Dave Newton <da...@solaraccess.com>.
> Say, seriously, ask him how he learned $foo.isEmpty() works in the first
> place?

I made him learn it.   :D

> That looks and reads nicely (assuming you read English) and at first
> glance I really like it - for collections. ... but I get nervous about
> what would happen if $var is an integer. How the engine defines "empty"
> (Null? Zero? -1? < 1.0 ?) will surely vary.

I think null, but that's just me--to me "empty" implies "that doesn't really
exist," whereas zero exists and would be a separate test.

It's also a "convention" thing (for us): if it's a numeric then I tell them
(HA!) that the variable will always exist regardless of its value. If it's a
list it will always exist but might be empty.

So if I _were_ to add "empty" it would be true for nulls and zero-length
things. But again, that's just me.

Dave



---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


RE: Support for array.length ?

Posted by Tim Colson <tc...@cisco.com>.
> My designer says "I'd rather use isEmpty because that would 
> always work and I wouldn't have to rely on you [me, Dave] 
> to remember to put an EMPTY in the
> context, because you're a dork."
> 
> Tragically, that's more or less verbatim.

LOL :-)

Say, seriously, ask him how he learned $foo.isEmpty() works in the first
place? 

The Uber-lazy Developer in me had to fire up an IDE, create a collection
object, and then browse the list of methods that the IDE pulled up when
I type "collection."

The Designer in me had no flippin' clue. But since the Designer in me
was peeking, he also noticed fun stuff like .remove :

ArrayList alist = new ArrayList();
alist.add("A");
alist.add("B");
alist.add("C");
context.put("thingy", alist);

Template:
$thingy
#set ($ok = $thingy.remove(1) )
$thingy 
"Cool," says the Designer, "thingy now has one less item, but weird that
it removed the second item in the list."
#set ($MethodInvocationException = $thingy.remove(5) )
$thingy "Goes boom?? Why is that?" 
$arrayThingy.remove(1) "That blows up too!!?? Why is that???"

Thank goodness my Designer brain rarely talks to my Developer brain. ;-)

Seriously - my point is that the Designer I work with seems to find out
about what she can 'do' with objects based on the Velocity User Guide or
my lame Developer docs. So to her, "isEmpty()" is not an inherent
assumed feature of $list_of_foo any more than .remove(n).
 

> The only other way I might like to see it (him too) is:
> #if (empty $var)
+0

That looks and reads nicely (assuming you read English) and at first
glance I really like it - for collections. ... but I get nervous about
what would happen if $var is an integer. How the engine defines "empty"
(Null? Zero? -1? < 1.0 ?) will surely vary.

context.put("EMPTY", new Boolean (myIQ < 10) );
#if ($EMPTY) Tim is a snail! #end
#if (empty $EMPTY) Boom? #end

-Timo


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Re: Support for array.length ?

Posted by Dave Newton <da...@solaraccess.com>.
> He'd rather foist $array.isEmpty() on a Designer than $EMPTY. Blech!

I would too ;)

> We never hear Designer folks speaking up to let us know if what would
> make sense to THEM. That is likely because there aren't many Designers
> on the list because Velocity is appropriately easy to grok and they
> don't need to read this banter.

My designer says "I'd rather use isEmpty because that would always work and
I wouldn't have to rely on you [me, Dave] to remember to put an EMPTY in the
context, because you're a dork."

Tragically, that's more or less verbatim. And yeah, I had to tell him what a
"context" was.

But seriously, we have a very clear line of demarcation between the
developer and designer for one part of our app (we use it for email
templates).

The only other way I might like to see it (him too) is:

#if (empty $var)

like adding a 'not' only it understands lists, arrays, nulls, etc. and does
the appropriate thing.

So maybe just add a keyword and we can get on with our lives?

Dave



---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Re: Support for array.length ?

Posted by Nathan Bubna <na...@esha.com>.
Tim Colson said:
> > $objects is really an array or a List.  $objects.isEmpty()
> > should work for both or neither.
> > it already works for one, so B.C. dictates...
>
> Hah.
>
> $collection_obj.remove(n) works for one too, but I don't see folks
> clamoring to make remove() work 'magically' for any object. ;-)

yep.  for the same reason that you don't counter that by suggestting they use
a tool that takes either lists or arrays to do it (e.g.
$remover_tool.remove($list, $index) )

it's not a good idea any way you look at it.  (e.g.  it's a strawman argument
:)

> The slope is coated with grease. <grin>

maybe, but i still see clear paths in the middle.  insist all you like, but
the options here are not necessarily binary (PHP or StringTemplate).  speaking
of which, from the sound of things StringTemplate is closer to what you want
than Velocity.

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: Support for array.length ?

Posted by Tim Colson <tc...@cisco.com>.
> $objects is really an array or a List.  $objects.isEmpty() 
> should work for both or neither. 
> it already works for one, so B.C. dictates...

Hah. 

$collection_obj.remove(n) works for one too, but I don't see folks
clamoring to make remove() work 'magically' for any object. ;-)

The slope is coated with grease. <grin>

Timo


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Re: Support for array.length ?

Posted by Nathan Bubna <na...@esha.com>.
Tim Colson said:
> Nathan (below) whines about how adding one new key to the context is a
> pain for "developers". ;-)
>
> He'd rather foist $array.isEmpty() on a Designer than $EMPTY. Blech!
> Pfft! :-P

it's so true!

> I realize that despite talk about separation of Designer and Developer
> roles... most people on this list play both in the real world.
>
> So we often see features created or 'not' simply because a Dev dude does
> '!' like the look of something. I'm betting that Nathan's opinion is
> based on his own developer-motivated desire to be lazy and use
> $array.isEmpty() rather than add a line of java, recompile, and
> re-deploy.

yes, exactly!  laziness is one of my primary motivators.  i work hard to make
my life easier.  it feels good to be understood!

and in addition to my aforementioned developer-motivated desire, there's also
my designer-motivated desire to not have to ask the developer half of my brain
to add the $EMPTY variable and then wait for that to be done before i can
change the template.

> We never hear Designer folks speaking up to let us know if what would
> make sense to THEM. That is likely because there aren't many Designers
> on the list because Velocity is appropriately easy to grok and they
> don't need to read this banter.
>
> So whatever the decision on this one little thing, let's please not
> [over time] lose site of template simplicity and paint ourselves
> (developers) into a corner where Designers can NOT understand templates
> in 30 min.

agreed.  so let's make them not have to spend time thinking about whether
$objects is really an array or a List.  $objects.isEmpty() should work for
both or neither.  it already works for one, so B.C. dictates...

> That way lies the path of JSP with truly ugly scriptlets and we [mostly]
> agree that road is paved with pure eeeevil. ;-)

yep, like the fruiiits of the deeevil.

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: Support for array.length ?

Posted by Tim Colson <tc...@cisco.com>.
Nathan (below) whines about how adding one new key to the context is a
pain for "developers". ;-)

He'd rather foist $array.isEmpty() on a Designer than $EMPTY. Blech!
Pfft! :-P

I realize that despite talk about separation of Designer and Developer
roles... most people on this list play both in the real world. 

So we often see features created or 'not' simply because a Dev dude does
'!' like the look of something. I'm betting that Nathan's opinion is
based on his own developer-motivated desire to be lazy and use
$array.isEmpty() rather than add a line of java, recompile, and
re-deploy.

We never hear Designer folks speaking up to let us know if what would
make sense to THEM. That is likely because there aren't many Designers
on the list because Velocity is appropriately easy to grok and they
don't need to read this banter.

So whatever the decision on this one little thing, let's please not
[over time] lose site of template simplicity and paint ourselves
(developers) into a corner where Designers can NOT understand templates
in 30 min.

That way lies the path of JSP with truly ugly scriptlets and we [mostly]
agree that road is paved with pure eeeevil. ;-)

Cheers,
Timo
"Power corrupts and PowerPoint corrupts absolutely" - Vint Cerf

> -----Original Message-----
> From: Nathan Bubna [mailto:nathan@esha.com] 
> Sent: Tuesday, December 30, 2003 10:17 AM
> To: Velocity Users List
> Subject: Re: Support for array.length ?
> 
> 
> Tim Colson said:
> > > #set( $bar = $array.isEmpty() )
> > > just a little magic.  :)
> > > keeps things simple and pretty for designers.
> > > no new paradigm, no new syntax.
> >
> > Or...
> >
> >   context.put("EMPTY", new Boolean(array.length == 0));
> >
> >   #if ($EMPTY) #end
> >
> > ZERO magic. :-)
> > Simpler and pretty for designers.
> > Absolutely no new paradigm, no new syntax.
> 
> yeah, and a PITA for developers.  :)
> 
> some of us like to occasionally break MVC rules! we're not 
> StringTemplate
> conservatives nor PHP liberals.  we're Velocity moderates.
> 
> sorry, election year coming up; it rubs off.  ;)
> 
> 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
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Re: Support for array.length ?

Posted by Nathan Bubna <na...@esha.com>.
Tim Colson said:
> > #set( $bar = $array.isEmpty() )
> > just a little magic.  :)
> > keeps things simple and pretty for designers.
> > no new paradigm, no new syntax.
>
> Or...
>
>   context.put("EMPTY", new Boolean(array.length == 0));
>
>   #if ($EMPTY) #end
>
> ZERO magic. :-)
> Simpler and pretty for designers.
> Absolutely no new paradigm, no new syntax.

yeah, and a PITA for developers.  :)

some of us like to occasionally break MVC rules! we're not StringTemplate
conservatives nor PHP liberals.  we're Velocity moderates.

sorry, election year coming up; it rubs off.  ;)

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: Support for array.length ?

Posted by Tim Colson <tc...@cisco.com>.
> #set( $bar = $array.isEmpty() )
> just a little magic.  :)
> keeps things simple and pretty for designers.  
> no new paradigm, no new syntax.

Or...

  context.put("EMPTY", new Boolean(array.length == 0));

  #if ($EMPTY) #end

ZERO magic. :-)
Simpler and pretty for designers.
Absolutely no new paradigm, no new syntax.

Timo - not a broken record... more like a skipping CD ;-)






---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Re: Support for array.length ?

Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr said:
> On Dec 29, 2003, at 9:47 PM, Nathan Bubna wrote:
> > Geir Magnusson Jr said:
> >> I'm still not convinced that there are enough of these to warrant
> >> adding to VTL.
> >
> > agreed.  and on that, i'd rather have things stay as they are than add 
> > the
> > $isEmpty($array) syntax.  ugly and confusing.  might at least be a 
> > little better if it used # or @ or something instead of $.
> 
> I just started w/ $, but you're right - it's not a reference.  It's not 
> really a directive either.

true, but it's closer to a directive than a reference though.

> @isEmpty($foo)
> %isEmpty($foo)
> &isEmpty($foo)
> 
> #set($res = &isEmpty($foo))

blech.  my vote is still for

#set( $bar = $array.isEmpty() )

just a little magic.  :)
keeps things simple and pretty for designers.  
no new paradigm, no new syntax.

sorry if i'm starting to sound like a broken record. ;)

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: Support for array.length ?

Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Dec 29, 2003, at 9:47 PM, Nathan Bubna wrote:

> Geir Magnusson Jr said:
>
>> I'm still not convinced that there are enough of these to warrant
>> adding to VTL.
>
> agreed.  and on that, i'd rather have things stay as they are than add 
> the
> $isEmpty($array) syntax.  ugly and confusing.  might at least be a 
> little
> better if it used # or @ or something instead of $.

I just started w/ $, but you're right - it's not a reference.  It's not 
really a directive either.

@isEmpty($foo)
%isEmpty($foo)
&isEmpty($foo)

#set($res = &isEmpty($foo))

Hm

>
> 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: Support for array.length ?

Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr said:
> On Dec 12, 2003, at 1:18 PM, Nathan Bubna wrote:
> > Geir Magnusson Jr said:
> >> On Dec 11, 2003, at 2:21 PM, Will Glass-Husain wrote:
> >>> Just to throw my 2 cents in... I think JSP 2.0 treats an array as a
> >>> collection, for the purposes of "empty" and retrieving values.  If
> >>> you're
> >>> not familiar with the new JSP 2.0 expression language, it looks a lot
> >>> like
> >>> Velocity (but stricter-- no arbitrary method calls allowed).
> >>> Specifically
> >>> "empty" returns true for empty collections, arrays, and strings (or
> >>> any null
> >>> object), and the brackets work with lists,maps,arrays.  There's been
> >>> discussion of including a generic length operator (that would apply
> >>> to
> >>> collections, arrays, strings) but I'm not sure if it made it in.
> >>>
> >>> Maybe we should add non-method-dependent collection operators to the
> >>> language at some point.    length / empty / get   would be a good
> >>> start.
> >>> They could apply to collections, maps, arrays, and for good measure,
> >>> strings.  (treating a string as an array of characters).  Just a
> >>> thought.
> >
> > i like that thought.  this would be good "magic" behavior in my
> > opinion.
> > although, i think "size" or "size()" would be better than "length" if
> > we're
> > going to apply this to all collections.  maps and sets don't really
> > have
> > length per se.
> >
> > ...
> >> I was thinking along this line earlier, to add somthing like a VTL
> >> function :
> >>
> >> $size()
> >>
> >> $isEmpty()
> >>
> >> You'd get stuff like
> >>
> >>    #if( $isEmpty($foo) == false)
> >>       ...
> >>    #end
> >
> > -1 yuck.  i really don't like it.  on of the things i like about
> > velocity is
> > the simplicity and readability of the syntax.  IMHO, this would be a
> > major
> > regression in that area.  i think it'd be far better to just make
> > $myarray.size() and $myarray.isEmpty() magically work.
> >
>
> The problem I have w/ $myarray.size() being magically created is that
> the syntax lies.

aw, "lies" is such a harsh word.  ;)

>    size($myarray)
>
> is really explicit - that there is some kind of VTL facility size()
> that is doing something for you.  The other way
>
>     $myarray.size()
>
> doesn't give you a clue if it's magic or the code.

why does this matter to a template designer?  they (we) don't have to worry
about the difference between int and Integer types; i don't think it's a big
leap to treat array and List the same.

> I'm still not convinced that there are enough of these to warrant
> adding to VTL.

agreed.  and on that, i'd rather have things stay as they are than add the
$isEmpty($array) syntax.  ugly and confusing.  might at least be a little
better if it used # or @ or something instead of $.

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: Support for array.length ?

Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Dec 12, 2003, at 1:18 PM, Nathan Bubna wrote:

> Geir Magnusson Jr said:
>> On Dec 11, 2003, at 2:21 PM, Will Glass-Husain wrote:
>>> Just to throw my 2 cents in... I think JSP 2.0 treats an array as a
>>> collection, for the purposes of "empty" and retrieving values.  If
>>> you're
>>> not familiar with the new JSP 2.0 expression language, it looks a lot
>>> like
>>> Velocity (but stricter-- no arbitrary method calls allowed).
>>> Specifically
>>> "empty" returns true for empty collections, arrays, and strings (or
>>> any null
>>> object), and the brackets work with lists,maps,arrays.  There's been
>>> discussion of including a generic length operator (that would apply 
>>> to
>>> collections, arrays, strings) but I'm not sure if it made it in.
>>>
>>> Maybe we should add non-method-dependent collection operators to the
>>> language at some point.    length / empty / get   would be a good
>>> start.
>>> They could apply to collections, maps, arrays, and for good measure,
>>> strings.  (treating a string as an array of characters).  Just a
>>> thought.
>
> i like that thought.  this would be good "magic" behavior in my 
> opinion.
> although, i think "size" or "size()" would be better than "length" if 
> we're
> going to apply this to all collections.  maps and sets don't really 
> have
> length per se.
>
> ...
>> I was thinking along this line earlier, to add somthing like a VTL
>> function :
>>
>> $size()
>>
>> $isEmpty()
>>
>> You'd get stuff like
>>
>>    #if( $isEmpty($foo) == false)
>>       ...
>>    #end
>
> -1 yuck.  i really don't like it.  on of the things i like about 
> velocity is
> the simplicity and readability of the syntax.  IMHO, this would be a 
> major
> regression in that area.  i think it'd be far better to just make
> $myarray.size() and $myarray.isEmpty() magically work.
>

The problem I have w/ $myarray.size() being magically created is that 
the syntax lies.

   size($myarray)

is really explicit - that there is some kind of VTL facility size() 
that is doing something for you.  The other way

    $myarray.size()

doesn't give you a clue if it's magic or the code.

I'm still not convinced that there are enough of these to warrant 
adding to VTL.

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: Support for array.length ?

Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson Jr said:
> On Dec 11, 2003, at 2:21 PM, Will Glass-Husain wrote:
> > Just to throw my 2 cents in... I think JSP 2.0 treats an array as a
> > collection, for the purposes of "empty" and retrieving values.  If
> > you're
> > not familiar with the new JSP 2.0 expression language, it looks a lot
> > like
> > Velocity (but stricter-- no arbitrary method calls allowed).
> > Specifically
> > "empty" returns true for empty collections, arrays, and strings (or
> > any null
> > object), and the brackets work with lists,maps,arrays.  There's been
> > discussion of including a generic length operator (that would apply to
> > collections, arrays, strings) but I'm not sure if it made it in.
> >
> > Maybe we should add non-method-dependent collection operators to the
> > language at some point.    length / empty / get   would be a good
> > start.
> > They could apply to collections, maps, arrays, and for good measure,
> > strings.  (treating a string as an array of characters).  Just a
> > thought.

i like that thought.  this would be good "magic" behavior in my opinion.
although, i think "size" or "size()" would be better than "length" if we're
going to apply this to all collections.  maps and sets don't really have
length per se.

...
> I was thinking along this line earlier, to add somthing like a VTL
> function :
>
> $size()
>
> $isEmpty()
>
> You'd get stuff like
>
>    #if( $isEmpty($foo) == false)
>       ...
>    #end

-1 yuck.  i really don't like it.  on of the things i like about velocity is
the simplicity and readability of the syntax.  IMHO, this would be a major
regression in that area.  i think it'd be far better to just make
$myarray.size() and $myarray.isEmpty() magically work.

> but I can't think of terribly many of these and wonder why we'd add the
> whole functionality needed to support this.  I thought people might
> want to extend the 'functions', but then I can't see why this is any
> better than just adding a tool to the context.  IOW, I can't see why
> this is so much better than
>
>    #if($tool.isEmpty($foo) == false)
>      ...
>    #end
>
> Is there enough to support something like this?

no. :)

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: Support for array.length ?

Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Dec 11, 2003, at 2:21 PM, Will Glass-Husain wrote:

> Just to throw my 2 cents in... I think JSP 2.0 treats an array as a
> collection, for the purposes of "empty" and retrieving values.  If 
> you're
> not familiar with the new JSP 2.0 expression language, it looks a lot 
> like
> Velocity (but stricter-- no arbitrary method calls allowed).  
> Specifically
> "empty" returns true for empty collections, arrays, and strings (or 
> any null
> object), and the brackets work with lists,maps,arrays.  There's been
> discussion of including a generic length operator (that would apply to
> collections, arrays, strings) but I'm not sure if it made it in.
>
> Maybe we should add non-method-dependent collection operators to the
> language at some point.    length / empty / get   would be a good 
> start.
> They could apply to collections, maps, arrays, and for good measure,
> strings.  (treating a string as an array of characters).  Just a 
> thought.

I did an attempt at JSTL-like functionality that you can use in 
proggies called Jexl - it's over in commons.  I didn't stop w/ JSTL as 
they didn't allow arbitrary method invocation, which at the time, I 
thought was a big mistake.  I still think it's a mistake, but I heard 
some noises that it will be fixed.

Anyway...

I was thinking along this line earlier, to add somthing like a VTL 
function :

$size()

$isEmpty()

You'd get stuff like

   #if( $isEmpty($foo) == false)
      ...
   #end

but I can't think of terribly many of these and wonder why we'd add the 
whole functionality needed to support this.  I thought people might 
want to extend the 'functions', but then I can't see why this is any 
better than just adding a tool to the context.  IOW, I can't see why 
this is so much better than

   #if($tool.isEmpty($foo) == false)
     ...
   #end

Is there enough to support something like this?

geir

>
> WILL
>
> ----- Original Message -----
> From: "J. B. Rainsberger" <jb...@rogers.com>
> To: "Velocity Users List" <ve...@jakarta.apache.org>
> Sent: Thursday, December 11, 2003 11:09 AM
> Subject: Re: Support for array.length ?
>
>
>> Geir Magnusson Jr wrote:
>>
>> <snip />
>>
>>> I then thought about treating an Object[] as a collection as far as 
>>> we
>>> could, returning things like size(), iterator(), etc where possible.
>>> This doesn't seem to be too insane, but also is, when caught by 
>>> surprise
>>> by the idea,  more magic yecchy behavior.  However, if you aren't 
>>> caught
>>> by surprise, and think about it, it isn't all bad.
>>
>> It's a collection -- just a fixed-size one. Why /not/ treat it like a
>> collection? It's not Velocity's fault that Java couldn't escape its
>> heritage.
>> -- 
>> J. B. Rainsberger,
>> Diaspar Software Services
>> http://www.diasparsoftware.com :: +1 416 791-8603
>> Let's write software that people understand
>>
>>
>> ---------------------------------------------------------------------
>> 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: Support for array.length ?

Posted by Will Glass-Husain <wg...@forio.com>.
Just to throw my 2 cents in... I think JSP 2.0 treats an array as a
collection, for the purposes of "empty" and retrieving values.  If you're
not familiar with the new JSP 2.0 expression language, it looks a lot like
Velocity (but stricter-- no arbitrary method calls allowed).  Specifically
"empty" returns true for empty collections, arrays, and strings (or any null
object), and the brackets work with lists,maps,arrays.  There's been
discussion of including a generic length operator (that would apply to
collections, arrays, strings) but I'm not sure if it made it in.

Maybe we should add non-method-dependent collection operators to the
language at some point.    length / empty / get   would be a good start.
They could apply to collections, maps, arrays, and for good measure,
strings.  (treating a string as an array of characters).  Just a thought.

WILL

----- Original Message ----- 
From: "J. B. Rainsberger" <jb...@rogers.com>
To: "Velocity Users List" <ve...@jakarta.apache.org>
Sent: Thursday, December 11, 2003 11:09 AM
Subject: Re: Support for array.length ?


> Geir Magnusson Jr wrote:
>
> <snip />
>
> > I then thought about treating an Object[] as a collection as far as we
> > could, returning things like size(), iterator(), etc where possible.
> > This doesn't seem to be too insane, but also is, when caught by surprise
> > by the idea,  more magic yecchy behavior.  However, if you aren't caught
> > by surprise, and think about it, it isn't all bad.
>
> It's a collection -- just a fixed-size one. Why /not/ treat it like a
> collection? It's not Velocity's fault that Java couldn't escape its
> heritage.
> -- 
> J. B. Rainsberger,
> Diaspar Software Services
> http://www.diasparsoftware.com :: +1 416 791-8603
> Let's write software that people understand
>
>
> ---------------------------------------------------------------------
> 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: Support for array.length ?

Posted by "J. B. Rainsberger" <jb...@rogers.com>.
Geir Magnusson Jr wrote:

<snip />

> I then thought about treating an Object[] as a collection as far as we 
> could, returning things like size(), iterator(), etc where possible. 
> This doesn't seem to be too insane, but also is, when caught by surprise 
> by the idea,  more magic yecchy behavior.  However, if you aren't caught 
> by surprise, and think about it, it isn't all bad.

It's a collection -- just a fixed-size one. Why /not/ treat it like a 
collection? It's not Velocity's fault that Java couldn't escape its 
heritage.
-- 
J. B. Rainsberger,
Diaspar Software Services
http://www.diasparsoftware.com :: +1 416 791-8603
Let's write software that people understand


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Re: Support for array.length ?

Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Dec 10, 2003, at 11:27 AM, Nathan Bubna wrote:

>
> well, if we're gonna hack in a magic property, why go with ".length"?  
> why not
> make believe that arrays have a getSize() method?  and for that 
> matter, if we
> ever get around to adding $array[0] type access, why not make the 
> syntax be
> $array.get(0)?

It's not a magic property, nor a new idea.  I bet many Java programmers 
would swear that .length is a property of Object[], and it really is a 
debate on semantics (because it isn't a field, just something done by 
the compiler).

My original thought pattern was "Hey, lets do something like jexl/jstl 
where there's a magic size() method/function that will return the size 
of whatever", and then I thought "Ew..."

I then thought about treating an Object[] as a collection as far as we 
could, returning things like size(), iterator(), etc where possible. 
This doesn't seem to be too insane, but also is, when caught by 
surprise by the idea,  more magic yecchy behavior.  However, if you 
aren't caught by surprise, and think about it, it isn't all bad.

However, I did want to give .length a try.  It works fine.  The only 
problem is that it opens another door, that of field access :)

>
>> I did the change - if no one comes up with a good arg against, I'll
>> commit.
>
> i'd rather make the ways arrays and lists behave *more* consistently in
> templates, not less.  i don't think the distinction between arrays and 
> lists
> is something that template authors should have to concern themselves 
> with.

Exactly.  We already treat them as an iterable in #foreach().  I think 
that can be the basis of our argument - since you can do

#foreach($foo in $foolist)
#end

you should be able to

$foolist.size()

I'll get the code in when I get back so we can play.  I also found a 
bug when doing this :)

geir
-- 
Geir Magnusson Jr                                   203-247-1713(m)
geir@4quarters.com


-- 
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: Support for array.length ?

Posted by Claude Brisson <cl...@savoirweb.com>.
Christopher wrote :
> +1 I like Nathan's point of view.

+1 also

> OTOH, many people do not read manuals and will try .length and
> then give up...

they will at least try .size or read the FM before giving up, no ?

> Ugh... so should vel support .getSize(0), .size and .length?

(you meant get(0), I guess)

-1 for this one

only one syntax should be allowed for one behaviour - and we should not cheat with list method names : suppose I inherit from a list
and define both getSize() and getLength()...

> Also +1, for the $array[$index] syntax.

+1 also

So, to summarize my proposal :

 - add support for [n] to the lists
 - add support for .size to the arrays

=> array and list access is the same and the only redundancy in the syntax is that for a list you can write .get(n) or [n]

CloD



---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Re: Support for array.length ?

Posted by Ch...@dlr.de.
+1 I like Nathan's point of view.

OTOH, many people do not read manuals and will try .length and
then give up... Ugh... so should vel support .getSize(0), .size
and .length?

Also +1, for the $array[$index] syntax.

just my EUR 0.02...
Cheers,
Christoph

Nathan Bubna wrote:
> Geir Magnusson said:
>[snip] 
>>The only comfort is that since .length is a hack in the langauge too,
>>we'd be in good company.
> 
> well, if we're gonna hack in a magic property, why go with ".length"?  why not
> make believe that arrays have a getSize() method?  and for that matter, if we
> ever get around to adding $array[0] type access, why not make the syntax be
> $array.get(0)?
> 
>>I did the change - if no one comes up with a good arg against, I'll
>>commit.
> 
> i'd rather make the ways arrays and lists behave *more* consistently in
> templates, not less.  i don't think the distinction between arrays and lists
> is something that template authors should have to concern themselves with.
> 
> Nathan Bubna
> nathan@esha.com

-- 
:) Christoph Reck


---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


Re: Support for array.length ?

Posted by Nathan Bubna <na...@esha.com>.
Geir Magnusson said:
> On Nov 26, 2003, at 4:19 AM, Peter Lammich wrote:
> > Gernot Hueller wrote:
> >> I know velocity can only introspect Methods, not member variables, but
> >> perhaps you could make an exception for arrays?
> >> Arrays are basically suported with foreach iteration.
> >> Now it would be great if I could also say "$myarray.length items
> >> displayed".
> >> Is this possible somehow now?
> >> If not, does someone agree this could be implemented?
> >>
> >> I think .length support should be possible only IF the passed
> >> variable is an
> >> array, and for nothing else.
...
> Oh, hell.  This is such an awful thing to add, but I can't come up with
> a solid argument to fight my instinct.   Anyone can help?

hmm.  i don't have a killer argument, but i do have a wild suggestion...

> I see that this is just a property except that we are allowing people
> to do awful things, because if you wanted to switch the model from an
> array to a Collection of any sort, you'd need to put a wrapper around
> it to add a getLength() method (or get(String) and support "length") or
> else the template would be useless.
>
> I guess all templates are written to a data model, and I suppose if you
> want to hang yourself....  Yech.
>
> The only comfort is that since .length is a hack in the langauge too,
> we'd be in good company.

well, if we're gonna hack in a magic property, why go with ".length"?  why not
make believe that arrays have a getSize() method?  and for that matter, if we
ever get around to adding $array[0] type access, why not make the syntax be
$array.get(0)?

> I did the change - if no one comes up with a good arg against, I'll
> commit.

i'd rather make the ways arrays and lists behave *more* consistently in
templates, not less.  i don't think the distinction between arrays and lists
is something that template authors should have to concern themselves with.

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: Support for array.length ?

Posted by Geir Magnusson <ge...@adeptra.com>.
On Nov 26, 2003, at 4:19 AM, Peter Lammich wrote:

> Gernot Hueller wrote:
>
>> Dear all,
>>
>> I know velocity can only introspect Methods, not member variables, but
>> perhaps you could make an exception for arrays?
>> Arrays are basically suported with foreach iteration.
>> Now it would be great if I could also say "$myarray.length items  
>> displayed".
>> Is this possible somehow now?
>> If not, does someone agree this could be implemented?
>>
>> I think .length support should be possible only IF the passed  
>> variable is an
>> array, and for nothing else.
>>
>> (I wasn't sure if this is a velocity-user or velocity-dev question so  
>> I sent
>> to both. Sorry if anyone is bothered)
>>
>>
> Just for the case that you are not able to pass a util-class to the  
> velocity context:
> There is a way to get the array length by using the reflection API:
>    #set($params = [$array.getClass().forName("java.lang.Object")])
>    #set  
> ($glm=$array.getClass().forName("java.lang.reflect.Array").getMethod("g 
> etLength",$params.toArray($array.getClass().getDeclaredClasses())))
>
>    #set ($params = [$array])
>    #set ($length = $glm.invoke(0,$params.toArray()))
>
> This is a very dirty hack, but works. (I have no possibility to pass a  
> $tool or $util variable to velocity context)
>
> Add .length support for arrays if you don't wanna see velocity abused  
> as in the example above !

That was a beautiful mess.  Brought a tear to my eye. The simplicity of  
MVC!

Oh, hell.  This is such an awful thing to add, but I can't come up with  
a solid argument to fight my instinct.   Anyone can help?

I see that this is just a property except that we are allowing people  
to do awful things, because if you wanted to switch the model from an  
array to a Collection of any sort, you'd need to put a wrapper around  
it to add a getLength() method (or get(String) and support "length") or  
else the template would be useless.

I guess all templates are written to a data model, and I suppose if you  
want to hang yourself....  Yech.

The only comfort is that since .length is a hack in the langauge too,  
we'd be in good company.

I did the change - if no one comes up with a good arg against, I'll  
commit.

geir

-- 
Geir Magnusson Jr                                   203-247-1713(m)
geir@4quarters.com


-- 
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: Support for array.length ?

Posted by Peter Lammich <la...@ls5.cs.uni-dortmund.de>.
Gernot Hueller wrote:

>Dear all,
>
>I know velocity can only introspect Methods, not member variables, but
>perhaps you could make an exception for arrays?
>Arrays are basically suported with foreach iteration.
>Now it would be great if I could also say "$myarray.length items displayed".
>Is this possible somehow now?
>If not, does someone agree this could be implemented?
>
>I think .length support should be possible only IF the passed variable is an
>array, and for nothing else.
>
>(I wasn't sure if this is a velocity-user or velocity-dev question so I sent
>to both. Sorry if anyone is bothered)
>
>  
>
Just for the case that you are not able to pass a util-class to the 
velocity context:
There is a way to get the array length by using the reflection API:
    #set($params = [$array.getClass().forName("java.lang.Object")])
    #set 
($glm=$array.getClass().forName("java.lang.reflect.Array").getMethod("getLength",$params.toArray($array.getClass().getDeclaredClasses())))

    #set ($params = [$array])
    #set ($length = $glm.invoke(0,$params.toArray()))

This is a very dirty hack, but works. (I have no possibility to pass a 
$tool or $util variable to velocity context)

Add .length support for arrays if you don't wanna see velocity abused as 
in the example above !



---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-user-help@jakarta.apache.org


RE: Support for array.length ?

Posted by James Carman <ja...@carmanconsulting.com>.
Why don't you just write a little ViewHelper class?  That solves the problem
you have without requiring a change to the VTL (which I doubt you're going
to get anyway).

-----Original Message-----
From: Geir Magnusson Jr [mailto:geir@4quarters.com] 
Sent: Tuesday, November 25, 2003 10:24 AM
To: Velocity Users List
Subject: Re: Support for array.length ?



On Nov 25, 2003, at 5:58 AM, Gernot Hueller wrote:

> Dear all,
>
> I know velocity can only introspect Methods, not member variables, but 
> perhaps you could make an exception for arrays? Arrays are basically 
> suported with foreach iteration. Now it would be great if I could also 
> say "$myarray.length items displayed".
> Is this possible somehow now?
> If not, does someone agree this could be implemented?
>
> I think .length support should be possible only IF the passed variable
> is an
> array, and for nothing else.

The problem here is that you (the template author) shouldn't know about 
the specific class of your data thats put into the context.  Rather, 
the model should be clear.  That's why accessing fields directly is 
discouraged via not being able to access.

geir

>
> (I wasn't sure if this is a velocity-user or velocity-dev question so
> I sent
> to both. Sorry if anyone is bothered)
>
> --
> GMX Weihnachts-Special: Seychellen-Traumreise zu gewinnen!
>
> Rentier entlaufen. Finden Sie Rudolph! Als Belohnung winken tolle 
> Preise. http://www.gmx.net/de/cgi/specialmail/
>
> +++ GMX - die erste Adresse für Mail, Message, More! +++
>
>
> ---------------------------------------------------------------------
> 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: Support for array.length ?

Posted by Geir Magnusson Jr <ge...@4quarters.com>.
On Nov 25, 2003, at 5:58 AM, Gernot Hueller wrote:

> Dear all,
>
> I know velocity can only introspect Methods, not member variables, but
> perhaps you could make an exception for arrays?
> Arrays are basically suported with foreach iteration.
> Now it would be great if I could also say "$myarray.length items 
> displayed".
> Is this possible somehow now?
> If not, does someone agree this could be implemented?
>
> I think .length support should be possible only IF the passed variable 
> is an
> array, and for nothing else.

The problem here is that you (the template author) shouldn't know about 
the specific class of your data thats put into the context.  Rather, 
the model should be clear.  That's why accessing fields directly is 
discouraged via not being able to access.

geir

>
> (I wasn't sure if this is a velocity-user or velocity-dev question so 
> I sent
> to both. Sorry if anyone is bothered)
>
> -- 
> GMX Weihnachts-Special: Seychellen-Traumreise zu gewinnen!
>
> Rentier entlaufen. Finden Sie Rudolph! Als Belohnung winken
> tolle Preise. http://www.gmx.net/de/cgi/specialmail/
>
> +++ GMX - die erste Adresse für Mail, Message, More! +++
>
>
> ---------------------------------------------------------------------
> 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: Support for array.length ?

Posted by Bill Boland <bo...@comcast.net>.
Gernot,

Although this is not a solution built into the Velocity syntax, it is quite
easy to create a tool bean that can be used to provide this. It might be
good to add something like this to a standard library of utility methods

    /**
     * Returns the collection or array size.
     * Returns 0 for all other object types.
     */
    public static int size( Object obj )
    {
        if ( obj != null )
        {
            if ( obj.getClass().isArray() )
            {
                return ((Object[]) obj).length;
            }
            else if ( obj instanceof Collection )
            {
                return ((Collection) obj).size();
            }
        }

        return 0;
    }

If this is a function of a tool bean assigned to the key "util", then you
could write "$util.size($myarray)" to get the length of the array. This will
work with Collections as well.

bill

-----Original Message-----
From: Gernot Hueller [mailto:g.hueller@gmx.at] 
Sent: Tuesday, November 25, 2003 2:58 AM
To: velocity-user@jakarta.apache.org; velocity-dev@jakarta.apache.org
Subject: Support for array.length ?

Dear all,

I know velocity can only introspect Methods, not member variables, but
perhaps you could make an exception for arrays?
Arrays are basically suported with foreach iteration.
Now it would be great if I could also say "$myarray.length items displayed".
Is this possible somehow now?
If not, does someone agree this could be implemented?

I think .length support should be possible only IF the passed variable is an
array, and for nothing else.

(I wasn't sure if this is a velocity-user or velocity-dev question so I sent
to both. Sorry if anyone is bothered)

-- 
GMX Weihnachts-Special: Seychellen-Traumreise zu gewinnen!

Rentier entlaufen. Finden Sie Rudolph! Als Belohnung winken
tolle Preise. http://www.gmx.net/de/cgi/specialmail/

+++ GMX - die erste Adresse f|r Mail, Message, More! +++


---------------------------------------------------------------------
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