FYI: this email will be boring personal background followed by relevant organizational and technical stuff; skip ahead if you only want the latter. :)
So... i've been playing around with a fair number of next steps for VelocityTools. at this point, my local branch is well beyond the point that i can easily check stuff in piece by piece. everything has begun to overlap and a variety of half-finished ideas are littered about. this has all been compounded by a myriad of personal life demands on my time over the past year and the fact that my employer has me working on a mix of Turbine/Velocity and SpringMVC/JSP apps over that same year. while i've been able to use GenericTools classes for the former apps, the reality is that i haven't used VelocityView or VelocityStruts in quite some time. and it doesn't look like we'll ever use VelocityStruts (at least in its current incarnation) at my paid job. I, unfortunately, have had little leverage in our technology choices since i shifted to the part-time work + part-time grad studies life. i'm in the process of shifting back to full-time, but it may be some time until an opportunity to influence a new project arises. all these things (in coincidental conjunction with coming changes in Jakarta's project organization and the always-not-quite-ready Velocity 1.5) leave a number of questions, ideas, and concerns about what is next for VelocityTools. Concern #1 - VelocityStruts 1.2 appears to be in fine shape. No major bugs reported. But a Struts 1.3.x is approaching, and i personally have no idea what--if anything--might need to change on our end to be compatible. I also don't really have time or interest in pursuing that. Concern #2 - The above is without even acknowledging the planned Struts/Webwork merger for Struts Action 2.0. Webwork at least used to have Velocity support. i've no idea what the plans are there. which lead to... Question #1 - Does anyone else want to take point on the future of VelocityStruts? I'm content to help support and maintain VelocityStruts 1.2 for a while, but beyond that, i think i need to bow out of the game. if no one steps up, VelocityTools 1.3 won't support Struts 1.3 features and may not even turn out to be compatible. if that turns out to be true, then it might be time to drop VelocityStruts (or hand it off to the Struts folks) and move on to a VelocityTools 2.x without a VelocityStruts component. then there's also the more positive stuff... Idea #1 - between what http://wiki.apache.org/jakarta-commons/Logging/StaticLog talks about, Tomcat's annoying dependence on commons-logging, and the many improvements i've made to logging in Velocity 1.5, i am making the transition from being a big advocate of using commons-logging in the Velocity world to being rather opposed to it. i want to back commons-logging use out of VelocityView and GenericTools as soon as we are able to depend on Velocity 1.5. Idea #2 - I want to GenericTools to be Configurable via toolbox parameters. but Configurable is a VelocityView interface. the three-part package issue has officially gotten in the way. but i think we can get around it in a very Velocity-ish way: let's drop/deprecate the ViewTool and Configurable interfaces and, instead, just use reflection in ViewToolInfo to identify and leverage tools that have init(Object) or configure(Map) methods. this is one of the things i have working locally and will hopefully check in soon, barring strong objections. Idea #3 - We've talked about adopting Veltag. i definitely have this itch and have been developing toolbox support for it. i'm well on my way to completing this, but it means some very big internal changes for the servlets. too much code was being duplicated between the improved VelocityViewTag (yeah, i think we should rename it) and VelocityViewServlet. so i've factored that out into a bare VelocityView class that has the necessary support for both. Idea #4 - So-called "standalone" toolbox support (http://issues.apache.org/jira/browse/VELTOOLS-8). The VelocityView object above is web-centric, but i agree, it'd be nice to make toolbox support for non-j2ee Velocity apps easy. i haven't done any work here, but i'm thinking it will probably require some heavy package re-organization. it would just be easier to go 2.x and not have to worry about being B.C. Idea #5 - Tool use syntax simplification. I've made a fair number of tweaks along this line a both before and after VelocityTools 1.2 was released. using the profound ugliness that is JSP syntax (JSTL only helps a little) has only sharpened my appetite for syntactic elegance. expect to see more of this from me, and please give feedback or suggestions in this area. all of these lead to... Question #2 - What do you think of these ideas? Question #3 - Does anyone really want any of these in a VelocityTools 1.3? Or should we just move on to work on a VelocityTools 2? Question #4 - Are there any other "big" ideas out there for a VelocityTools 2? then my last and lesser question is... Question #5 - joda-time (http://joda-time.sourceforge.net/) is great. i want to see support for it in DateTool (or a new tool if need be). i haven't had time to tackle this myself. has anyone else done this yet? anyone want to? i'll probably get to it eventually, but as you can see from the above, i already have bitten off a lot to chew. :) thanks for listening. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
