You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Nathan Bubna <na...@esha.com> on 2002/11/07 02:17:38 UTC

[velstruts] moving forward... Was: Re: Book addressing Velocity Struts

Gabe said:
> A friend just pointed me to the fact that Ted Husted's book
> "Struts in Action" is out now. It includes one chapter
> (chapter 17, 16 pages) on Struts using Velocity as the view
> layer.
...

cool.

> We so much publicity, we now really have to get the Struts
> 1.1 integration done... :-)

yeah, and maybe a release?  even just a beta would probably be a good
thing...

also, i'd like to see us put together a list of features or changes people
would like to see improved/revisited/added.  i think that would help us to
focus efforts and hopefully get some others involved.

to start things off:

- 1.1 features?
    i submitted a patch for StrutsUtils and an ActionMessagesTool to take
advantage of ActionMessages.  are there other new features we should be
hooking into?  validator stuff maybe?  i'm not sure.

- docs and examples...  always need more :-)

- customizable/improved logging
    i think it's time we addressed this.  the ServletLogger is wonderfully
convenient and should stay the default, but i'd like to have the same
customizability that Velocity proper has. (i.e.  i want the power and flex
of log4j :)

- customizable tool manager (this should be fairly easy)
    we've gone to some effort to provide extensible tool management, now i
think it'd be good to allow other implementations of ToolboxManager (or at
least of XMLToolboxManager) to be easily plugged into the
VelocityViewServlet.

- pooling of tool instances
    this goes kind of hand-in-hand with the previous one.  if we want to
pool tools, we'll need to be able to offer/use a ToolboxManager that handles
pooling (perhaps as default?) which means allowing run-time customization of
VelocityViewServlet's ToolboxManager.  and of course, if we do this, we
should make the standard tools poolable.

- VelocityLayoutServlet
    it seems to me there's been a fair bit of demand in the past for a
servlet that does a "two-pass render" to make handling layouts and such
easier.  a while back i submitted the VelocityLayoutServlet to handle this
neatly and to do more elegant and pleasant error handling.  i passed it on
to the list as something that might be good in a contrib folder.  i'm ready
to make a bigger push for its inclusion either in contrib or the main.  i
think it could be quite useful and would be willing to put in a bit more
time on it if there's interest.

- things could probably use a bit of formatting and javadoc
clean-up/improvement

- other suggestions?

i may find time to work on some of these, but i'm hoping some others might
step up and take a whack at these.  it's doubtful that i'll have time to
work on them all (and of course, i'd still need a committer to commit them).

Nathan Bubna
nathan@esha.com



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [velstruts] moving forward... Was: Re: Book addressing Velocity Struts

Posted by Nathan Bubna <na...@esha.com>.
Gabe said:
..
> - Fix parameter parser problem reported by Jeff

parameter parser problem?  did i miss this?

> - Add paging tool contributed by Nathan
...

if this goes in, i'll try to find some time to set up a decent example app
with it.

> I'll compile a list of open issues integrating yours and mine. Then
> we can set priorities and define madatory/optional features. I'd
> favor not to add many new features for a release 1 but focus on
> Struts 1.1 support and documentation. But let's discuss the details
> when I have the list.

sounds good.

Nathan Bubna
nathan@esha.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [velstruts] moving forward... Was: Re: Book addressing Velocity Struts

Posted by Gabriel Sidler <si...@teamup.com>.
I moved this thread from the user list here.

I also collected a number of open issues, some overlapping with yours, Nathan.

- Resolve configuration issues. Currently, the resource loader and the logger
   are hard-coded in VVS and overwrite the configuration in Velocity.properties.
   This is inflexible and confusing.

- Struts 1.1 support. As far as I understand it right now, the major item
   is support for multiple application modules within one web application.
   (means multiple configration files, multiple message resources, etc.)

- Documentation
   - Fix current tools documentation. Several files are out of sync.
   - Complete user guide.

- Examples
   - Create a Struts 1.1 example. Take one of the existing Struts 1.1
     examples and replace the view layer with Velocity.
   - Create a blank Velocity-Struts application as the starting point
     for development.

- Fix parameter parser problem reported by Jeff

- Add paging tool contributed by Nathan

- Add improved ToolLoader contributed by Bill



I'll compile a list of open issues integrating yours and mine. Then
we can set priorities and define madatory/optional features. I'd
favor not to add many new features for a release 1 but focus on
Struts 1.1 support and documentation. But let's discuss the details
when I have the list.

Gabe





Nathan Bubna wrote:

...


>>We so much publicity, we now really have to get the Struts
>>1.1 integration done... :-)
>>
> 
> yeah, and maybe a release?  even just a beta would probably be a good
> thing...
> 
> also, i'd like to see us put together a list of features or changes people
> would like to see improved/revisited/added.  i think that would help us to
> focus efforts and hopefully get some others involved.
> 
> to start things off:
> 
> - 1.1 features?
>     i submitted a patch for StrutsUtils and an ActionMessagesTool to take
> advantage of ActionMessages.  are there other new features we should be
> hooking into?  validator stuff maybe?  i'm not sure.
> 
> - docs and examples...  always need more :-)
> 
> - customizable/improved logging
>     i think it's time we addressed this.  the ServletLogger is wonderfully
> convenient and should stay the default, but i'd like to have the same
> customizability that Velocity proper has. (i.e.  i want the power and flex
> of log4j :)
> 
> - customizable tool manager (this should be fairly easy)
>     we've gone to some effort to provide extensible tool management, now i
> think it'd be good to allow other implementations of ToolboxManager (or at
> least of XMLToolboxManager) to be easily plugged into the
> VelocityViewServlet.
> 
> - pooling of tool instances
>     this goes kind of hand-in-hand with the previous one.  if we want to
> pool tools, we'll need to be able to offer/use a ToolboxManager that handles
> pooling (perhaps as default?) which means allowing run-time customization of
> VelocityViewServlet's ToolboxManager.  and of course, if we do this, we
> should make the standard tools poolable.
> 
> - VelocityLayoutServlet
>     it seems to me there's been a fair bit of demand in the past for a
> servlet that does a "two-pass render" to make handling layouts and such
> easier.  a while back i submitted the VelocityLayoutServlet to handle this
> neatly and to do more elegant and pleasant error handling.  i passed it on
> to the list as something that might be good in a contrib folder.  i'm ready
> to make a bigger push for its inclusion either in contrib or the main.  i
> think it could be quite useful and would be willing to put in a bit more
> time on it if there's interest.
> 
> - things could probably use a bit of formatting and javadoc
> clean-up/improvement
> 
> - other suggestions?
> 
> i may find time to work on some of these, but i'm hoping some others might
> step up and take a whack at these.  it's doubtful that i'll have time to
> work on them all (and of course, i'd still need a committer to commit them).
> 
> Nathan Bubna
> nathan@esha.com
> 
> 
> 
> --
> To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
> For additional commands, e-mail: <ma...@jakarta.apache.org>
> 
> 


-- 
--
Gabriel Sidler
Software Engineer, Eivycom GmbH, Zurich, Switzerland


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


Re: [velstruts] moving forward... Was: Re: Book addressing Velocity Struts

Posted by Nathan Bubna <na...@esha.com>.
Gonzalo said:
> > also, i'd like to see us put together a list of features or changes
people
> > would like to see improved/revisited/added.  i think that would help us
to
> > focus efforts and hopefully get some others involved.
>
> How about support for floats?

actually, that is more of a matter for Velocity proper, and not really in
the scope of the Velocity-Tools subproject.

Nathan Bubna
nathan@esha.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: [velstruts] moving forward... Was: Re: Book addressing Velocity Struts

Posted by Gonzalo Diethelm <go...@aditiva.com>.
Before this gets out of hand, please notice the smileys!

> How about support for floats?
> 
> (ducks and runs, uselessly, and has to face the public outrage...)
> 
> With lots of :-), ;-), 8-), 8), ...

Again: this was intended as a joke.


-- 
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>


RE: [velstruts] moving forward... Was: Re: Book addressing Velocity Struts

Posted by Gonzalo Diethelm <go...@vtr.net>.
> also, i'd like to see us put together a list of features or changes people
> would like to see improved/revisited/added.  i think that would help us to
> focus efforts and hopefully get some others involved.

How about support for floats?

(ducks and runs, uselessly, and has to face the public outrage...)

With lots of :-), ;-), 8-), 8), ...


--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com


--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>