Tiles
  1. Tiles
  2. TILES-541

VelocityAttributeRenderer does not pass context attributes

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.2.2
    • Fix Version/s: None
    • Component/s: tiles-velocity
    • Labels:
      None

      Description

      VelocityTilesRequestContextFactory creates VelocityTilesRequestContext which still holds the velocity Context passed from outside.

      However, VelocityAttributeRenderer ignores this VelocityTilesRequestContext completely and creates a new context with velocityView.createContext(request, response).

      As a result the context map that is passed to Tiles from outside is not passed along to Velocity. Among other things, it is causing issues with integration of Spring, Tiles and Velocity.

        Activity

        Hide
        Nicolas Le Bas added a comment -

        Thanks for this detailed description of your solution. But I still don't clearly understand the problem it solves.

        My guess:

        • if you use spring's VelocityViewResolver, you can access the velocity toolbox but not Tiles' taglib.
        • if you use spring's TilesViewResolver, you can access Tiles' taglib but not the velocity toolbox.

        About your solution:
        I'm not sure about forwarding the velocity context this way, I don't want to expose the "local" variables (#set) to the included pages. It seems dangerous, for instance an included page might change the value of the caller's variable. At the very least, you should wrap the caller's context in a new velocity Context.

        Show
        Nicolas Le Bas added a comment - Thanks for this detailed description of your solution. But I still don't clearly understand the problem it solves. My guess: if you use spring's VelocityViewResolver, you can access the velocity toolbox but not Tiles' taglib. if you use spring's TilesViewResolver, you can access Tiles' taglib but not the velocity toolbox. About your solution: I'm not sure about forwarding the velocity context this way, I don't want to expose the "local" variables (#set) to the included pages. It seems dangerous, for instance an included page might change the value of the caller's variable. At the very least, you should wrap the caller's context in a new velocity Context.
        Hide
        Konrad Garus added a comment -

        Perhaps this will shed some light. Actually, the workaround in this post could be used for the patch: http://squirrel.pl/blog/2012/02/20/spring-velocity-tile/

        Show
        Konrad Garus added a comment - Perhaps this will shed some light. Actually, the workaround in this post could be used for the patch: http://squirrel.pl/blog/2012/02/20/spring-velocity-tile/
        Hide
        Nicolas Le Bas added a comment -

        We'll be rewriting the VelocityAttributeRenderer for Tiles 3.1, in order to make it usable without servlets (see
        TREQ-13. Using VelocityEngine instead of VelocityView may also help
        the integration with Spring.

        I'm not sure I understand the details of the problem you describe, especially the issues you're referering to. A patch may not help that much, however I'm interested in a test case.

        Show
        Nicolas Le Bas added a comment - We'll be rewriting the VelocityAttributeRenderer for Tiles 3.1, in order to make it usable without servlets (see TREQ-13 . Using VelocityEngine instead of VelocityView may also help the integration with Spring. I'm not sure I understand the details of the problem you describe, especially the issues you're referering to. A patch may not help that much, however I'm interested in a test case.
        Nicolas Le Bas made changes -
        Field Original Value New Value
        Assignee Nicolas Le Bas [ nlebas ]
        Hide
        Konrad Garus added a comment -

        If this bug is confirmed and you are interested in a patch, I could create one.

        Show
        Konrad Garus added a comment - If this bug is confirmed and you are interested in a patch, I could create one.
        Konrad Garus created issue -

          People

          • Assignee:
            Nicolas Le Bas
            Reporter:
            Konrad Garus
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development