Velocity Tools
  1. Velocity Tools
  2. VELTOOLS-94

Document standard use cases with J2EE filters

    Details

    • Type: Improvement Improvement
    • Status: Resolved
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 2.0
    • Fix Version/s: 2.0
    • Component/s: Documentation
    • Labels:
      None
    • Environment:
      all

      Description

      (yet another docs reminder...)

      There are some use cases concerning J2EE filters that I'd like to address/document before releasing 2.0 final:

      1. sharing the VelocityView with filters - made very easy in 2.x, using:

      view = (VelocityView)servletContext.getAttribute(VelocityView.class.getName())

      but the loat-a-startup flag must be set on the servlets for the view to be initialized at the time the filter is called.

      [BTW, the VelocityView(ServletContext) exists but is not yet fully coded - init is not yet called. We should either comment it for now or refactor VV.init/configure to work either with a ServletConfig or ServletContext. Personally I don't need it at all.]

      2. having a filter add objects in the context: very easy, objects should be put in targeted scopes using request/session/application attributes.

      3. having a filter add a tools property (that will be added to newly created request/session tools using bean setters or configure): I'm not really sure about this one. With the current codebase, it is necessary to subclass both the VV and the ToolboxFactory to circumvent protected accesses to be able to do sthing like this:

      VV.getToolboxFactory().putProperties(scope,props)

      I'd vote for having those two methods made public.

      [BTW, subclassing of the VV also requires for now the subclassing of the VVS... maybe ServletUtils.getVelocityView could check a configuration property like "velocity.tools.view.class=" containing the classname of the VelocityView subclass to be used]

        Activity

        Hide
        Nathan Bubna added a comment -

        I think all of these things are pretty much taken care of at this point.

        Show
        Nathan Bubna added a comment - I think all of these things are pretty much taken care of at this point.
        Hide
        Nathan Bubna added a comment -

        As of revision 673880, you can now tell ServletUtils to use a VelocityView subclass by adding an init-param with the key of

        org.apache.velocity.tools.view.class

        and a value of the subclass' canonical class name. This makes it much easier to override things in VelocityView that used to be in VelocityViewServlet.

        Show
        Nathan Bubna added a comment - As of revision 673880, you can now tell ServletUtils to use a VelocityView subclass by adding an init-param with the key of org.apache.velocity.tools.view.class and a value of the subclass' canonical class name. This makes it much easier to override things in VelocityView that used to be in VelocityViewServlet.
        Hide
        Nathan Bubna added a comment -

        Ok, i think #1 is fully taken care of by revision 647050.

        #2 still seems trivial as it stands. Not sure if there's something you think should be done there.

        the usecase for #3 is still a little mysterious to me. and no, i think you only need to intercept the ViewToolContext and call putToolProperty(String, Object) before the targeted tool(s) are created. it shouldn't be necessary to subclass all those classes. but without understanding what the goal here is, it's hard to be sure if that would do it. in any case, if you say you have use for it, go ahead and make VelocityView.getToolboxFactory() public. but i still think any changes to the ToolboxFactory need to go through the configure() method. Of course, making late changes like that can only affect request tools or tools in subsequently created session Toolboxes, so there are limits to what further factory configuration can accomplish, but i suppose that should be obvious considering their scoping.

        Show
        Nathan Bubna added a comment - Ok, i think #1 is fully taken care of by revision 647050. #2 still seems trivial as it stands. Not sure if there's something you think should be done there. the usecase for #3 is still a little mysterious to me. and no, i think you only need to intercept the ViewToolContext and call putToolProperty(String, Object) before the targeted tool(s) are created. it shouldn't be necessary to subclass all those classes. but without understanding what the goal here is, it's hard to be sure if that would do it. in any case, if you say you have use for it, go ahead and make VelocityView.getToolboxFactory() public. but i still think any changes to the ToolboxFactory need to go through the configure() method. Of course, making late changes like that can only affect request tools or tools in subsequently created session Toolboxes, so there are limits to what further factory configuration can accomplish, but i suppose that should be obvious considering their scoping.
        Hide
        Nathan Bubna added a comment -

        Be sure to use o.a.v.t.view.ServletUtils.getVelocityView(ServletConfig config) to get a VelocityView for a filter to use, unless you explicitly do not want to share your VelocityView across a ServletContext for some reason.

        Also, the VelocityView(ServletContext) ctor is not meant to init. a ServletConfig is required for full init (or you can use the separate init methods), ask me if you want more of my thoughts on this. i'm currently tight on time. use VelocityView(ServletConfig) if you want to create and init in the same step.

        I'm not entirely sure what you are trying to accomplish in #2 and #3 above. i may just not have the time to think it through. there probably is already a way to do it, but i may have missed something. in general, if you want to add tool properties, you should be adding them via a FactoryConfiguration. we can streamline that and make such late configuration additions easier, but any change to the factory should go through the configure() method at this point. i might be open to changing that, but would require some convincing.

        It would be nice to make it easier to subclass VV. i'm definitely open to making that possible.

        Show
        Nathan Bubna added a comment - Be sure to use o.a.v.t.view.ServletUtils.getVelocityView(ServletConfig config) to get a VelocityView for a filter to use, unless you explicitly do not want to share your VelocityView across a ServletContext for some reason. Also, the VelocityView(ServletContext) ctor is not meant to init. a ServletConfig is required for full init (or you can use the separate init methods), ask me if you want more of my thoughts on this. i'm currently tight on time. use VelocityView(ServletConfig) if you want to create and init in the same step. I'm not entirely sure what you are trying to accomplish in #2 and #3 above. i may just not have the time to think it through. there probably is already a way to do it, but i may have missed something. in general, if you want to add tool properties, you should be adding them via a FactoryConfiguration. we can streamline that and make such late configuration additions easier, but any change to the factory should go through the configure() method at this point. i might be open to changing that, but would require some convincing. It would be nice to make it easier to subclass VV. i'm definitely open to making that possible.

          People

          • Assignee:
            Unassigned
            Reporter:
            Claude Brisson
          • Votes:
            0 Vote for this issue
            Watchers:
            0 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development