Tapestry 5
  1. Tapestry 5
  2. TAP5-79

Improve Tapestry's property expression language to include OGNL-like features

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 5.0.15
    • Fix Version/s: 5.1.0.0
    • Component/s: None
    • Labels:
      None

      Description

      While I really the use of prop and it's typesafeness, I still find myself frequently in need of more complicated expressions enough that I would be willing to pay the speed penalty of reflection in order to not have to define a public getter for it. In some situations, you can't actually make an equivilent getter. For instance, in integrations tests I've had more than one situation where I wanted to call a setter with a specific value from the template. With OGNL this is easy but with prop it's impossible. I would very much like to see prop remain the default binding but have OGNL available when it's needed. I think not having it would be a severe limitation of T5.

        Issue Links

          Activity

          Hide
          Howard M. Lewis Ship added a comment -

          I'd like to extend the property expression language quite a bit more, but keep it concise and type safe. But not before first stable release.

          Show
          Howard M. Lewis Ship added a comment - I'd like to extend the property expression language quite a bit more, but keep it concise and type safe. But not before first stable release.
          Hide
          Howard M. Lewis Ship added a comment -

          Some ideas:

          boolean invert: ! property

          comparison operators: lt, lte, gt, gte, eq, ==, neq, !=

          (using names rather than symbols because these expressions appear in XML and we want to avoid using entities)

          simple math: + - * /

          Invocation of methods with parameters (this would require the ability to evaluate sub expressions).

          Generalized array/list/map access via [ ] operator.
          myarray[0], mylist[0], mymap[key]

          List creation: [ 1, 2, 3]

          Map creation:

          { 'fred':'flinstone', 'barney':'rubble' }

          List comprehensions / selection/ projection (syntax TBA)

          Show
          Howard M. Lewis Ship added a comment - Some ideas: boolean invert: ! property comparison operators: lt, lte, gt, gte, eq, ==, neq, != (using names rather than symbols because these expressions appear in XML and we want to avoid using entities) simple math: + - * / Invocation of methods with parameters (this would require the ability to evaluate sub expressions). Generalized array/list/map access via [ ] operator. myarray [0] , mylist [0] , mymap [key] List creation: [ 1, 2, 3] Map creation: { 'fred':'flinstone', 'barney':'rubble' } List comprehensions / selection/ projection (syntax TBA)
          Hide
          Howard M. Lewis Ship added a comment -

          Coming along great so far; have ANTLR integrated.

          However, something I didn't realize until just now: under the new scheme, binding to "true" or "false" will be a full PropBinding instance, i.e., non-cacheable.

          I think what I might do is add an internal marker annotation, @Invariant, that can indicate to PropBinding instances that the value is invariant, even though it looks like a property expression.

          Show
          Howard M. Lewis Ship added a comment - Coming along great so far; have ANTLR integrated. However, something I didn't realize until just now: under the new scheme, binding to "true" or "false" will be a full PropBinding instance, i.e., non-cacheable. I think what I might do is add an internal marker annotation, @Invariant, that can indicate to PropBinding instances that the value is invariant, even though it looks like a property expression.
          Hide
          Howard M. Lewis Ship added a comment -

          I think the PE is quite good for what it is, and with the error checks I just added is quite sufficient. Further work on it will be covered in new issues.

          Show
          Howard M. Lewis Ship added a comment - I think the PE is quite good for what it is, and with the error checks I just added is quite sufficient. Further work on it will be covered in new issues.

            People

            • Assignee:
              Howard M. Lewis Ship
              Reporter:
              Dan Adams
            • Votes:
              6 Vote for this issue
              Watchers:
              7 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development