Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Duplicate
    • Affects Version/s: 1.6
    • Fix Version/s: 1.6, 2.x
    • Component/s: Engine
    • Labels:
      None
    • Environment:
      Operating System: All
      Platform: All

      Description

      ok, the motive of this feature request is that we shouldn't have to distinguish
      between an $array and a $list when writing templates. this is already handled
      to a degree in the #foreach() directive which transparently handles both arrays
      and Lists (among other things), and it seems logically consistent with the way
      VTL already hides the difference between primitives and their wrappers (int vs.
      Integer).

      so, in this same spirit, i propose that we should enable template authors to
      access items by index, determine the size of, and manipulate (to a point) Lists
      and arrays identically. here's an example that demonstrates how i think this
      should work:

      Access Item at Index 2:
      $list.get(2) ##works already
      $array.get(2) ##doesn't work right now

      Determine size:
      $list.size() ##works already
      $array.size() ##wish this would work

      you get the idea, right? basically, i would like to have all operations that
      make sense for an array supported (which i believe means most List methods
      except the add(), remove(), and clear() ones).

      IMHO, this would simplify things for users noticeably and eliminate the need for
      such things as an ArrayTool in the VelocityTools library.

      at this point, i'm not sure what the best approach for implementing this is. it
      may simply be the automatic, transparent wrapping of arrays inserted into the
      context with some sort of ArrayList wrapper class. or i suppose it could
      involve some crazy Uberspect trickery.

      now all we need is someone with the time to whip up a patch...

        Issue Links

          Activity

          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Resolved Resolved
          935d 13h 14m 1 Nathan Bubna 25/Sep/07 19:07
          Mark Thomas made changes -
          Workflow Default workflow, editable Closed status [ 12551747 ] jira [ 12552282 ]
          Mark Thomas made changes -
          Workflow jira [ 12325240 ] Default workflow, editable Closed status [ 12551747 ]
          Nathan Bubna made changes -
          Link This issue duplicates VELOCITY-533 [ VELOCITY-533 ]
          Nathan Bubna made changes -
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 2.0 [ 12310291 ]
          Fix Version/s 1.6 [ 12310290 ]
          Resolution Duplicate [ 3 ]
          Hide
          Nathan Bubna added a comment -

          This is a duplicate of VELOCITY-533.

          Show
          Nathan Bubna added a comment - This is a duplicate of VELOCITY-533 .
          Henning Schmiedehausen made changes -
          Bugzilla Id 33833
          Component/s Engine [ 12311337 ]
          Component/s Source [ 12310214 ]
          Hide
          Henning Schmiedehausen added a comment -

          Also a custom Uberspect using ArrayIterator might already solve that problem. See whiteboard/henning/jdk15 on how to write your own Uberspect.

          Show
          Henning Schmiedehausen added a comment - Also a custom Uberspect using ArrayIterator might already solve that problem. See whiteboard/henning/jdk15 on how to write your own Uberspect.
          Will Glass-Husain made changes -
          Link This issue is duplicated by VELOCITY-232 [ VELOCITY-232 ]
          Hide
          Will Glass-Husain added a comment -

          I agree.

          Show
          Will Glass-Husain added a comment - I agree.
          Will Glass-Husain made changes -
          Assignee Velocity-Dev List [ velocity-dev@jakarta.apache.org ]
          Environment Operating System: All
          Platform: All
          Operating System: All
          Platform: All
          Bugzilla Id 33833
          Affects Version/s 1.6 [ 12310290 ]
          Affects Version/s 1.5 [ 12310253 ]
          Description ok, the motive of this feature request is that we shouldn't have to distinguish
          between an $array and a $list when writing templates. this is already handled
          to a degree in the #foreach() directive which transparently handles both arrays
          and Lists (among other things), and it seems logically consistent with the way
          VTL already hides the difference between primitives and their wrappers (int vs.
          Integer).

          so, in this same spirit, i propose that we should enable template authors to
          access items by index, determine the size of, and manipulate (to a point) Lists
          and arrays identically. here's an example that demonstrates how i think this
          should work:

          Access Item at Index 2:
          $list.get(2) ##works already
          $array.get(2) ##doesn't work right now

          Determine size:
          $list.size() ##works already
          $array.size() ##wish this would work

          you get the idea, right? basically, i would like to have all operations that
          make sense for an array supported (which i believe means most List methods
          except the add(), remove(), and clear() ones).

          IMHO, this would simplify things for users noticeably and eliminate the need for
          such things as an ArrayTool in the VelocityTools library.

          at this point, i'm not sure what the best approach for implementing this is. it
          may simply be the automatic, transparent wrapping of arrays inserted into the
          context with some sort of ArrayList wrapper class. or i suppose it could
          involve some crazy Uberspect trickery.

          now all we need is someone with the time to whip up a patch...
          ok, the motive of this feature request is that we shouldn't have to distinguish
          between an $array and a $list when writing templates. this is already handled
          to a degree in the #foreach() directive which transparently handles both arrays
          and Lists (among other things), and it seems logically consistent with the way
          VTL already hides the difference between primitives and their wrappers (int vs.
          Integer).

          so, in this same spirit, i propose that we should enable template authors to
          access items by index, determine the size of, and manipulate (to a point) Lists
          and arrays identically. here's an example that demonstrates how i think this
          should work:

          Access Item at Index 2:
          $list.get(2) ##works already
          $array.get(2) ##doesn't work right now

          Determine size:
          $list.size() ##works already
          $array.size() ##wish this would work

          you get the idea, right? basically, i would like to have all operations that
          make sense for an array supported (which i believe means most List methods
          except the add(), remove(), and clear() ones).

          IMHO, this would simplify things for users noticeably and eliminate the need for
          such things as an ArrayTool in the VelocityTools library.

          at this point, i'm not sure what the best approach for implementing this is. it
          may simply be the automatic, transparent wrapping of arrays inserted into the
          context with some sort of ArrayList wrapper class. or i suppose it could
          involve some crazy Uberspect trickery.

          now all we need is someone with the time to whip up a patch...
          Hide
          Will Glass-Husain added a comment -

          I like the idea of just wrapping arrays in ArrayList somehow, probably in the Uberspector. I've set this as a 1.6 feature.

          WILL

          Show
          Will Glass-Husain added a comment - I like the idea of just wrapping arrays in ArrayList somehow, probably in the Uberspector. I've set this as a 1.6 feature. WILL
          Jeff Turner made changes -
          Field Original Value New Value
          issue.field.bugzillaimportkey 33833 12315235
          Nathan Bubna created issue -

            People

            • Assignee:
              Unassigned
              Reporter:
              Nathan Bubna
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development