[snip] > > I know some of this > > functionality has already been implemented (especially in the case of the > > vel-struts class), but seeing as the current codebase is extremely young and > > umm...unrefined :-), i think some rigorous competition can only help, right? > > Sure - can any of it be combined? Competition is good, but we also want to > limit the confusion to users - avoid major overlap (minor isn't so bad...)
hmm. well, a lot of what MessageTool does is *already* duplicated in the vel-struts package. both StrutsHtmlTool and StrutsBeanTool have similar code offering message resource access. and IMO both classes do it poorly. so my recommendation would be to completely pull those portions out. take a look at MessageTool. it's designed to make much better use of velocity's abilities, and i think it is a better approach. the LinkTool class (which is not Struts dependant) also duplicates some portions of the StrutsHtmlTool (link(), baseRef(), and whatnot), and again I would argue it does a far better job of dealing with links in templates. in the same vein, my MathTool (also not Struts dependent) is IMO more flexible and robust and has been used (read tested) quite a bit. lastly, the PullTool/SearchTool code currently has no peer in the velocity-tools heirarchy. so, while i readily admit they are less useful to people, i'm probably not the only one who needs such functionality. parameter parsing and search results pagination are pretty common needs. overall my impression of the vel-struts package so far is that it is written to mimic the functionality of the struts taglibs. frankly, i think that is the wrong approach. i think having a "make-velocity-in-struts-work-like-jsp-in-struts" mentality limits this project to a utility for developers who want to port apps from struts/jsp to struts/velocity. seeing as i wanted to build an app from scratch with struts and velocity, i found the current vel-struts codebase to be poorly organized and unintuitive. i don't mean to be contentious, but i think the current direction of the vel-struts project is wrong. you and the other developers are free to disagree, of course, and you can take or leave my code as you wish. I'm just trying to help out a bit. > > Anyway, i found developing with these attached tools to be quite pleasant > > and i feel inclined to share. > > That's great. We will pull back the Commons 'rupert' as well and get this > going. cool. sounds like there's more demand (and supply :-) out there for a DateTool lately. it's probably time you guys put one in the tools sub-project to get people using the same one. i like that last suggestion today about making it grab the locale from the request. maybe sometime this week i'll clean-up/rewrite my old rupert one to do that and follow the pattern of the ones i contributed today. Nathan Bubna [EMAIL PROTECTED] -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
