Velocity
  1. Velocity
  2. VELOCITY-406

Improved Syntax for Maps and Collections

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Engine
    • Labels:
      None

      Description

      I would like to see some syntatic sugar for Maps and Collections and perhaps other Objects too.
      (I have read that there will be a syntax for map literals in 1.5, that's a first step.)

      I want to have something like in groovy: http://groovy.codehaus.org/Collections
      Scroll down to "Slicing with the subscript operator".

      PS: Please do never implement this terrible confusing groovy map bean syntax, where "map.foo" ist equivalent to "map.get("foo")".

        Activity

        Mark Thomas made changes -
        Workflow Default workflow, editable Closed status [ 12551935 ] jira [ 12552706 ]
        Mark Thomas made changes -
        Workflow jira [ 12330484 ] Default workflow, editable Closed status [ 12551935 ]
        Byron Foster made changes -
        Resolution Fixed [ 1 ]
        Status Reopened [ 4 ] Closed [ 6 ]
        Nathan Bubna made changes -
        Resolution Fixed [ 1 ]
        Status Closed [ 6 ] Reopened [ 4 ]
        Hide
        Nathan Bubna added a comment -

        Please note this feature in the change log before closing the issue.

        Show
        Nathan Bubna added a comment - Please note this feature in the change log before closing the issue.
        Byron Foster made changes -
        Resolution Fixed [ 1 ]
        Status Open [ 1 ] Closed [ 6 ]
        Hide
        Byron Foster added a comment -

        Thanks Will, that worked. As Nathan say, it works with Native arrays, because of VELOCITY-533, and other stuff

        Show
        Byron Foster added a comment - Thanks Will, that worked. As Nathan say, it works with Native arrays, because of VELOCITY-533 , and other stuff
        Hide
        Nathan Bubna added a comment -

        Yeah, arrays, maps, lists and objects with get(key) methods. See the IndexTestCase for demo. It looks pretty thorough.

        Show
        Nathan Bubna added a comment - Yeah, arrays, maps, lists and objects with get(key) methods. See the IndexTestCase for demo. It looks pretty thorough.
        Hide
        Will Glass-Husain added a comment -

        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.

        Show
        Will Glass-Husain added a comment - 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.
        Hide
        Will Glass-Husain added a comment -

        I added Byron to the "velocity-developers" jira-group. Does that help? You should see a "Resolve Issue" link in the upper left.

        WILL

        Show
        Will Glass-Husain added a comment - I added Byron to the "velocity-developers" jira-group. Does that help? You should see a "Resolve Issue" link in the upper left. WILL
        Hide
        Nathan Bubna added a comment -

        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.

        Show
        Nathan Bubna added a comment - 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.
        Hide
        Byron Foster added a comment -

        I don't think I can, I have no "close" workflow items...

        Show
        Byron Foster added a comment - I don't think I can, I have no "close" workflow items...
        Hide
        Nathan Bubna added a comment - - edited

        Looks great, Byron! If you're finished, please mark this resolved.

        Show
        Nathan Bubna added a comment - - edited Looks great, Byron! If you're finished, please mark this resolved.
        Hide
        Byron Foster added a comment - - 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")

        Show
        Byron Foster added a comment - - 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 made changes -
        Fix Version/s 1.6 [ 12310290 ]
        Hide
        Nathan Bubna added a comment -

        Lacking a champion for this, i don't think we can plan on this for 1.6.

        Show
        Nathan Bubna added a comment - Lacking a champion for this, i don't think we can plan on this for 1.6.
        Hide
        Stephen Colebourne added a comment -

        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.

        Show
        Stephen Colebourne added a comment - 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.
        Hide
        Jörg Gottschling added a comment -

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

        Show
        Jörg Gottschling added a comment - 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] )
        Henning Schmiedehausen made changes -
        Field Original Value New Value
        Component/s Engine [ 12311337 ]
        Fix Version/s 1.6 [ 12310290 ]
        Component/s Source [ 12310214 ]
        Hide
        Henning Schmiedehausen added a comment -

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

        Show
        Henning Schmiedehausen added a comment - 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...
        Hide
        Jörg Gottschling added a comment -

        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?

        Show
        Jörg Gottschling added a comment - 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?
        Hide
        Claude Brisson added a comment -

        > PS: Please do never implement this terrible confusing groovy map bean syntax, where "map.foo" ist equivalent to "map.get("foo")".

        Too late...

        What so confusing anyway ?


        Claude

        Show
        Claude Brisson added a comment - > PS: Please do never implement this terrible confusing groovy map bean syntax, where "map.foo" ist equivalent to "map.get("foo")". Too late... What so confusing anyway ? – Claude
        Jörg Gottschling created issue -

          People

          • Assignee:
            Unassigned
            Reporter:
            Jörg Gottschling
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development