I think it's a little bit confusing, because you could not distinguish between a property and an entry then. But I think, that's something one can get used to.

Are these syntax elements limited to the collection framework? Or can you just implement an interface or just some special methods to apply some syntactic sugar to your own classes. Does Velocity support the interface "Iterable" in 1.5?

Jörg Gottschling
added a comment - 04/Oct/05 21:44 I think it's a little bit confusing, because you could not distinguish between a property and an entry then. But I think, that's something one can get used to.
Are these syntax elements limited to the collection framework? Or can you just implement an interface or just some special methods to apply some syntactic sugar to your own classes. Does Velocity support the interface "Iterable" in 1.5?
Where can I get some infos about the new version?

Will think about Maps slices for 1.6. Iterable is supported if you use a custom Uberspect (see whiteboard/henning/jdk15). Groovy might have stolen the "horrible map syntax" from us, so there is nothing we can do here...

Henning Schmiedehausen
added a comment - 05/Nov/06 19:08 Will think about Maps slices for 1.6. Iterable is supported if you use a custom Uberspect (see whiteboard/henning/jdk15). Groovy might have stolen the "horrible map syntax" from us, so there is nothing we can do here...

Hm, ... I will have a look at this "Uberspect" and I hope it is not just a wrapper only for initial context objects.

Your comment makes me think, that this map.key syntax ist already part of the language? I do not think so, because I have not seen documentation or even a comment about this, before yours.

By the way: The syntax may be OK. One of the very ugly problems in Groovy (really ugly) is the Map creation syntax, where you can only use key with the same restriction like identifier. That is because they do not use quotation marks. def groovy =

{has : "a very", ugly : "map syntax"}

What you can NOT do: def groovy =

{"has a" : "nice map syntax"}

It is not a map syntax, it is a bean creation syntax....

So this is also a problem with the map.property syntax. Will a key like "3" work? #set( $third = $map.3 )

It's ok for some very commen cases like #set( $urlParameterValue = $request.parameter )

What i requested was the use of the slice operator, which unifies the syntax for maps an lists
#set( $third = $list[3] )
#set( $third = $map[3] )

Jörg Gottschling
added a comment - 06/Nov/06 07:50 Hm, ... I will have a look at this "Uberspect" and I hope it is not just a wrapper only for initial context objects.
Your comment makes me think, that this map.key syntax ist already part of the language? I do not think so, because I have not seen documentation or even a comment about this, before yours.
By the way: The syntax may be OK. One of the very ugly problems in Groovy (really ugly) is the Map creation syntax, where you can only use key with the same restriction like identifier. That is because they do not use quotation marks. def groovy =
{has : "a very", ugly : "map syntax"}
What you can NOT do: def groovy =
{"has a" : "nice map syntax"}
It is not a map syntax, it is a bean creation syntax....
So this is also a problem with the map.property syntax. Will a key like "3" work? #set( $third = $map.3 )
It's ok for some very commen cases like #set( $urlParameterValue = $request.parameter )
What i requested was the use of the slice operator, which unifies the syntax for maps an lists
#set( $third = $list [3] )
#set( $third = $map [3] )

Stephen Colebourne
added a comment - 25/Jan/08 12:46 I support this RFE for list access using [ ].
I expected the syntax $
{someList[1]}
to work in Velocity, and was surprised when it didn't. Perhaps VELOCITY-533 has made this more feasible?
Personally, I only need the 'get' behaviour, and not the 'set' behaviour, but they should be logically introduced together.
I also don't see the need for $
{someList.1}
to work - that seems like overkill syntax.

Added the $foo[1] style syntax. When reading values it's implemented by calling .get(<val>), so that the bracketed syntax is synonymous with .get(. This means it also works for getting Map values like $foo["junk"].

Setting this type of reference also works. for example:

#set($foo[2] = 3)

If the index value is an Integer, then it calls .set(Integer, <val>), otherwise it calls .put(<val>, <val>) which allows the setting of Map values with:

Byron Foster
added a comment - 01/Jan/09 17:04 - edited Added the $foo [1] style syntax. When reading values it's implemented by calling .get(<val>), so that the bracketed syntax is synonymous with .get(. This means it also works for getting Map values like $foo ["junk"] .
Setting this type of reference also works. for example:
#set($foo [2] = 3)
If the index value is an Integer, then it calls .set(Integer, <val>), otherwise it calls .put(<val>, <val>) which allows the setting of Map values with:
#set($foo ["garbage"] = "smelly")

Nathan Bubna
added a comment - 01/Jan/09 19:51 Hmm. I dunno a ton about JIRA, Close might be just for admins and the issue reporter. Do you have a "Resolve" workflow item? If not, then we need to get you some more perms or something.

Will Glass-Husain
added a comment - 02/Jan/09 00:12 by the way, I like this syntax.
Does it work for arrays? Since the syntax is similar to array syntax, most users will assume it works for arrays too.