I also find the VelocityTools attractive. Here is a post from the Velocity list on how one can use them seperate from the VelocityViewServlet. It wouldn't be too hard (from the description) to tie them in, and I'm sure that Nathan Bubna would help you do it on the Velocity list, and appreciate the even tighter integration between WW and Velocity. If it works well, and is configurable, I'm also sure that it would find its way into the WW2 distribution, from what I know of the project leaders. The post from velocity-users:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Robert Douglass said: > It is not initially clear whether it is easy to use VelocityTools without > the VelocityViewServlet, and how one might do so. good question. the first thing to recognize is that there are three very distinct parts to VelocityTools: VelocityStruts, VelocityView, and the GenericTools. the GenericTools are easy to use without the VVS. they're just plain java classes with no servlet dependencies. all you do is use them as their javadoc/documentation indicates. there really shouldn't be anything more to explain there. the tools in the VelocityView package are a little trickier. these generally are reliant on the servlet API. at least, you'll need to be in a web-environment to use them, and most can't be used directly without a ViewContext implementation. however, none of that requires using the VVS. it's good, but not everyone uses the tools with it. my company is actually using several of the VV tools in a Turbine app. to do this, we had to extend the tools to make them implement Turbine's own ApplicationTool interface. this was easy to do and is working out quite well for us. we've tried to design the VV tools to be easy to extend for just such reasons. if you have questions about how to do this or need help with it, just ask. i'll be happy to explain and can provide examples as well. using the VelocityStruts tools w/o the VVS is pretty much the same story as the VelocityView tools. although, you'll surely need some servlet to handle your velocity templates (jasper sure won't do it :), so why not use the VVS? now, if you're wanting to use VelocityTools' tool management stuff (defining toolbox in xml and such), then you still don't have to use the VVS. for the servlet environment, you can use the ServletToolboxManager and ChainedContext on your own. if you want to manage tools outside a servlet environment, then you can create your own toolbox manager pretty easily by extending the XMLToolboxManager. > The user's and developer's > guides for Velocity are excellent in showing how to use Velocity in a > generic application, but the Tools documentation either assumes that you'll > be using the VelocityViewServlet or that you're just smart enough to not > have to ask this question :-) point well taken. VelocityTools development has been largely servlet-oriented and heavily driven by the development of VelocityStruts. thus, the documentation is admittedly biased toward that use case. however, we are still seeking to keep the VelocityView and GenericTools packages viable in their own right. we have also tried to keep in mind the possibility of extending the toolbox management concept/code to work with other velocity environments/projects (e.g. DVSL) besides the VelocityViewServlet and VelocityStruts. if anyone is so interested, please feel free to open a dialogue on it. Nathan Bubna [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Fred Lamuette Sent: Wednesday, September 24, 2003 6:57 PM To: [EMAIL PROTECTED] Subject: RE: [OS-webwork] Struts user feedbak >-----Message d'origine----- >De : [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] la part de >Jason Carreira >Envoye : mercredi 24 septembre 2003 18:54 >A : [EMAIL PROTECTED] >Objet : RE: [OS-webwork] Struts user feedbak > > >See below > >> -----Original Message----- >> From: Fred Lamuette [mailto:[EMAIL PROTECTED] >> Sent: Wednesday, September 24, 2003 11:17 AM >> To: Webwork >> Subject: [OS-webwork] Struts user feedbak >> >> >> Althought I'm a struts user, WW2 features seem to be very >> exciting, so i'm testing WW2 for my next project. For the >> while, i'm writing a simple project in order to explore the >> WW2 features, and i'm rather impressed by your work. However >> I've some questions : >> >> 1/ We can use only ui tags from velocity (Renderer >> interface), do you plan quicky to support the other tags >> (URLTag , ...) ? >> > >I really need to learn more about Velocity so I can answer these >questions better.... > >I thought the URLTag wasn't needed because it just uses >UrlHelper.buildUrl(), which you can also use from Velocity? > I can use from velocity what is really in the velocity context. So, if UrlHelper is not in the context, i cant use it. BUT with the extension of velocity-tools, and particulary the toolbox manager included in the VelocityView package, you can make any tools available to the templates. This mechanism is the base for the use of the struts framework with velocity, where some struts ressources are made available via the toolbox manager. Hum, of course the choice of a WebWorkVelocityServlet is understandable for managing the ww tags, but relying on Velocity Tools is maybe a more stable choice, or complementary ... >> 2/ ValidationInterceptor controls fields from the Action, but >> maybe it would be nice to control http form parameters. Why i >> say that, it's because of the following example : public >> MyAction extends ActionSupport { >> private MyBean myBean = new myBean(); >> public MyBean getMyBean() >> {...} >> ... >> } >> >> public MyBean >> { >> private java.util.Date myDate; >> ... >> } >> >> HTML form >> #bodyTag( Form ... ) >> #tag( TextField "label=date" "name=myBean.myDate" >> value="myBean.myDate" ) ... >> >> If I want to validate that the string parameter sent by the >> form submission is a real date, how can i do with the >> validation framework ? With my own localized dateConverter >> (xwork-conversion.properties), i would transform a bad string >> value in a (Date)null. And with the definition of >> MyAction-validation.xml, I just could control that the field >> is required. So a bad string value for my date would be >> blocked but for a bad reason. That's why, I wonder if we >> could apply a validation to a different object/context, http >> parameters or action, it would be very flexible. We could >> create specific validator to control , for instance, a string >> represent a date. > >The type conversion does this... It validates that your String >represents a Date. I'm not sure (Pat?) how this is logged / added as an >error message (hopefully it would be added as a field error message). That was my question, my converter extends DefaultTypeConverter, but if my converter is unable to convert, how can i add field error message to WW2 ? I've got no context attached to WW2. > >> >> 3/ Dont you think the struts concept of ActionMessage is a >> good idea, a low-cost dev effort to store easyly a message >> (possibly localized) at the end of a action to inform the >> user in the view ("creation successful" ,...). > >You can easily add this to a base Action class you use as the parent of >all of your Action classes. I agree, it would be just for convenience > >> >> I've got a ton of other remarks but I let you digest ;-) >> >> WebWork2 will be a great web application framework. >> R.H. >> > >Thanks, > >Jason > >> >> >> ------------------------------------------------------- >> This sf.net email is sponsored by:ThinkGeek >> Welcome to geek heaven. >>> http://thinkgeek.com/sf > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork