Velocity
  1. Velocity
  2. VELOCITY-800

Subsequent invalid references cannot be resolved by InvalidReferenceEventHandler.invalidGetMethod

    Details

      Description

      If $foo is a java.lang.String and a template tried to do $foo.bar, one can use an InvalidReferenceEventHandler to resolve bar into a value. However, if the template tries to do $foo.bar.baz, the last part cannot be resolved using an InvalidReferenceEventHandler. I'll attach an example test case.

      1. SubsequentInvalidReferenceEventHandlerTest.java
        2 kB
        Quintin Siebers
      2. VELOCITY-800.patch
        7 kB
        Peter-Paul Kruijsen

        Activity

        Hide
        Peter-Paul Kruijsen added a comment -

        I've created a patch that could resolve this issue. It moves the result null check and invalidMethod / invalidGetMethod invocation from after to within the children loop. It also adds the test case attached by the reporter.

        Show
        Peter-Paul Kruijsen added a comment - I've created a patch that could resolve this issue. It moves the result null check and invalidMethod / invalidGetMethod invocation from after to within the children loop. It also adds the test case attached by the reporter.
        Hide
        Claude Brisson added a comment -

        I see two problems with your patch:

        • it doesn't handle the $invalid.prop case, only $valid.invalid.invalid case
        • it calculates the reference full name for every reference, which looks like overkill (we'd like to only calculate it whenever we encounter a null)

        There are other considerations about this feature:

        • how should tests on references behave? should #if($invalid) or #if($valid.invalid.invalid) also use the event handler and use its result? It's not the case for now.
        • would strict mode be impacted? Right now, strict mode and invalid reference events are orthogonal features.

        At start, this event handler was thought as a debugging feature, and not meant to include business logic. If you still think it's pertinent, could you elaborate a bit on your use case? Are you sure there isn't any easier way of handling it? For instance, have you considered using a custom uberspector?

        Show
        Claude Brisson added a comment - I see two problems with your patch: it doesn't handle the $invalid.prop case, only $valid.invalid.invalid case it calculates the reference full name for every reference, which looks like overkill (we'd like to only calculate it whenever we encounter a null) There are other considerations about this feature: how should tests on references behave? should #if($invalid) or #if($valid.invalid.invalid) also use the event handler and use its result? It's not the case for now. would strict mode be impacted? Right now, strict mode and invalid reference events are orthogonal features. At start, this event handler was thought as a debugging feature, and not meant to include business logic. If you still think it's pertinent, could you elaborate a bit on your use case? Are you sure there isn't any easier way of handling it? For instance, have you considered using a custom uberspector?

          People

          • Assignee:
            Unassigned
            Reporter:
            Quintin Siebers
          • Votes:
            1 Vote for this issue
            Watchers:
            3 Start watching this issue

            Dates

            • Created:
              Updated:

              Development