Velocity Tools
  1. Velocity Tools
  2. VELTOOLS-7

Add the VelocityWriter to the context of the VelocityViewServlet

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.1
    • Fix Version/s: 1.2
    • Component/s: None
    • Labels:
      None
    • Environment:
      Operating System: All
      Platform: All

      Description

      The reason and purpose of this is for performance situations as stated by
      Nikolaj.Brinch.Joergensen@sdk.sas.com

      Following the recent thread discussion...

      http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg07051.html
      http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg07066.html

      <snip>
      BUT...this shows where an enhancement would be nice to have. If the
      statement in the mergeTemplate() method of:

      template.merge( context, vw);

      was replaced with:

      performMerge( template, context, vm );

      where performMerge was a protected method of VelocityServlet with the
      original statement as its default behavior, then you could easily
      override this method in a subclass of VelocityServlet to place the
      writer into the context. The VelocityServlet could still manage the
      private writerPool.
      <\snip>

      An alternative solution would be to allow the writerPool, encoding and other
      private methods be protected so that it would be easier to override the
      mergerTemplate method so this could be implemented by the developer. Maybe both
      should be done.

      bill

        Activity

        Nathan Bubna made changes -
        Status Resolved [ 5 ] Closed [ 6 ]
        Nathan Bubna made changes -
        Resolution Fixed [ 1 ]
        Status Open [ 1 ] Resolved [ 5 ]
        Hide
        Nathan Bubna added a comment -
        Show
        Nathan Bubna added a comment - done, as of http://svn.apache.org/viewcvs?rev=321228&view=rev
        Tim Colson made changes -
        Affects Version/s 1.1 [ 12310347 ]
        Fix Version/s 1.2 [ 12310348 ]
        Bugzilla Id 9139
        Tim Colson made changes -
        Component/s Unknown [ 12310320 ]
        Tim Colson made changes -
        Fix Version/s Tools-1.2 [ 12310324 ]
        Project Velocity [ 12310104 ] VelocityTools [ 12310130 ]
        Component/s Tools [ 12310217 ]
        Affects Version/s Tools-1.1 [ 12310326 ]
        Component/s Unknown [ 12310320 ]
        Key VELOCITY-79 VELTOOLS-7
        Nathan Bubna made changes -
        Assignee Nathan Bubna [ nbubna ]
        Affects Version/s 1.3-rc1 [ 12310248 ]
        Affects Version/s Tools-1.1 [ 12310326 ]
        Bugzilla Id 9139
        Fix Version/s Tools-1.2 [ 12310324 ]
        Hide
        Nathan Bubna added a comment -

        breaking the template.merge(...) method out into a protected performMerge(...) sounds fine to me.

        Show
        Nathan Bubna added a comment - breaking the template.merge(...) method out into a protected performMerge(...) sounds fine to me.
        Will Glass-Husain made changes -
        Component/s Tools [ 12310217 ]
        Component/s Source [ 12310214 ]
        Bugzilla Id 9139
        Assignee Velocity-Dev List [ velocity-dev@jakarta.apache.org ]
        Description The reason and purpose of this is for performance situations as stated by
        Nikolaj.Brinch.Joergensen@sdk.sas.com

        Following the recent thread discussion...

        http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg07051.html
        http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg07066.html


        <snip>
        BUT...this shows where an enhancement would be nice to have. If the
        statement in the mergeTemplate() method of:
         
                    template.merge( context, vw);

        was replaced with:

                        performMerge( template, context, vm );

        where performMerge was a protected method of VelocityServlet with the
        original statement as its default behavior, then you could easily
        override this method in a subclass of VelocityServlet to place the
        writer into the context. The VelocityServlet could still manage the
        private writerPool.
        <\snip>


        An alternative solution would be to allow the writerPool, encoding and other
        private methods be protected so that it would be easier to override the
        mergerTemplate method so this could be implemented by the developer. Maybe both
        should be done. :)

        bill
        The reason and purpose of this is for performance situations as stated by
        Nikolaj.Brinch.Joergensen@sdk.sas.com

        Following the recent thread discussion...

        http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg07051.html
        http://www.mail-archive.com/velocity-user@jakarta.apache.org/msg07066.html


        <snip>
        BUT...this shows where an enhancement would be nice to have. If the
        statement in the mergeTemplate() method of:
         
                    template.merge( context, vw);

        was replaced with:

                        performMerge( template, context, vm );

        where performMerge was a protected method of VelocityServlet with the
        original statement as its default behavior, then you could easily
        override this method in a subclass of VelocityServlet to place the
        writer into the context. The VelocityServlet could still manage the
        private writerPool.
        <\snip>


        An alternative solution would be to allow the writerPool, encoding and other
        private methods be protected so that it would be easier to override the
        mergerTemplate method so this could be implemented by the developer. Maybe both
        should be done. :)

        bill
        Environment Operating System: All
        Platform: All
        Operating System: All
        Platform: All
        Jeff Turner made changes -
        Field Original Value New Value
        issue.field.bugzillaimportkey 9139 12314949
        Hide
        Will Glass-Husain added a comment -

        Took a look at this old enhancement request.

        VelocityServlet is officially now deprecated for the 1.5 release - no new
        fixes will be applied.

        Might this be applicable to the replacement VelocityViewServlet in the
        excellent subproject Velocity-Tools? Changing the title. Please evaluate.

        Also, if anyone is interested in writing a patch for this, it might help.

        Show
        Will Glass-Husain added a comment - Took a look at this old enhancement request. VelocityServlet is officially now deprecated for the 1.5 release - no new fixes will be applied. Might this be applicable to the replacement VelocityViewServlet in the excellent subproject Velocity-Tools? Changing the title. Please evaluate. Also, if anyone is interested in writing a patch for this, it might help.
        Hide
        Bill Boland added a comment -

        I'm not certain how getCurrentWriter() would help or what class this method
        would belong to. Could you describe it's use in a sample? Is this to
        encapsulate the pool? if so, how is the writer release back to the pool?

        In VelocityServlet, the mergetTemplate method creates/gets the writer and
        performs the merge. allowing no intermediate intervention by a subclass to
        include the writer object into the context. It them releases the writer back to
        a pool.

        Show
        Bill Boland added a comment - I'm not certain how getCurrentWriter() would help or what class this method would belong to. Could you describe it's use in a sample? Is this to encapsulate the pool? if so, how is the writer release back to the pool? In VelocityServlet, the mergetTemplate method creates/gets the writer and performs the merge. allowing no intermediate intervention by a subclass to include the writer object into the context. It them releases the writer back to a pool.
        Hide
        Geir Magnusson Jr added a comment -

        definitely will expose this somehow

        I assume something as straightforward as

        getCurrentWriter()

        would do it?

        Show
        Geir Magnusson Jr added a comment - definitely will expose this somehow I assume something as straightforward as getCurrentWriter() would do it?
        Bill Boland created issue -

          People

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

            Dates

            • Created:
              Updated:
              Resolved:

              Development