Given that 1.3 hasn't been released yet, and no-one seems to have an organised plan - I've just been adding features until someone says stop.
At the moment, you can use velocity with the rd.include() overhead by changing a property in your webwork.properties file. Shortly I will change the UI tags to eliminate the rd.include() overhead.
At this stage, in the 1.3 branch, I will try and eliminate the velocity dependency (so that it is backward compatible). This will probably be with a wrapper class that uses reflection to load velocity. If that proves too ugly, then I'll introduce the dependency.
So - for the moment, you can convert all your UI templates (you have created your own right?) to velocity. I have committed velocity examples of almost all the existing ones.
Peter - give me a call if you have any other questions.
Cheers,
Scott
Peter Kelley wrote:
Given that for some of us the dev meeting is at an unearthly hour of the morning :) (I am at GMT + 9.5) I'll comment here.Please can we have this in WW 1.3 ? What will it mean in terms of jars needed in our web application ? On Tue, 2003-02-04 at 17:17, Patrick Lightbody wrote:I just ran some tests, inspired by Scotts work on getting Velocity in place for the UI tags. I took it one step further and got rid rd.include() entirely (Like Scott had mentioned) and the performance boost was icredible. Basically, if we lock down to using velocity for the -UI tags- (note, this means that JSP views would still work), we get like a 10X performance increase as well as a huge scaling increase. I mean, it's so huge that it would be dumb for us not to take it. And mind you, I ran these tests on Orion and Resin, two of the fastest JSP implementations. So I'm going to un-propose my suggestion about using SiteMesh for the UI tags and instead propose that we stick 100% to only supporting velocity-based taglibs. Your JSP views will still look and act exactly the same: .... <ww:textfield ... /> ... The only difference is that instead of the TextFieldTag issueing an rd.include() request to some unknown URL (JSP or velocity), it uses Velocity to write -directly- to the JspWriter: template.merge(context, pageContext.getOut()); All the same support would exist (themes, tweaking, etc), but it would just be much faster. The downside is that if you have custom UI widgets, you'll have to convert them to velocity. Thoughts? Actually, don't write back to this. Instead, just show up to the dev meeting tomorrow. -Pat ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
-- ATLASSIAN - http://www.atlassian.com Expert J2EE Software, Services and Support ------------------------------------------------------- Need a simple, powerful way to track and manage issues? Try JIRA - http://www.atlassian.com/software/jira ------------------------------------------------------- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
