You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@velocity.apache.org by Gabriel Sidler <si...@teamup.com> on 2002/11/06 15:14:44 UTC
Book addressing Velocity Struts
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.
I read chapter 17 and think that it gives a very good and easy
to follow introduction on using Velocity with Struts as the
controller framework.
More details at http://www.manning.com/husted/index.html
There is also an e-book version for $22.
Ted Husted is an active commiter of the Jakarta Struts project.
He has been very helpful when we initially started the Velocity/Struts
integration.
We so much publicity, we now really have to get the Struts
1.1 integration done... :-)
Gabe
--
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>.
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>
[velstruts] moving forward... Was: Re: Book addressing Velocity Struts
Posted by Nathan Bubna <na...@esha.com>.
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>