On 3/10/06, Claude Brisson <[EMAIL PROTECTED]> wrote: > Hello Nathan > > Le jeudi 09 mars 2006 à 14:28 -0800, Nathan Bubna a écrit : > > 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. > > I'm not using Struts nor VelocityStruts, so of course I'm in favour of a > VelocityTools 2.x. I never used Struts since it always seemed quite > bloated to me, and that is the exact reason why I like the lightweight > aspects of VelocityTools. So I've always seen VelocityStruts as a very > paradoxal entity...
well, if you remember, the whole project was birthed out of the desire to use Velocity with Struts. :) > > Question #2 - What do you think of these ideas? > > Idea #1 - commons-logging: I'm quite neutral on this. > > Idea #2 - reflection: Great ! And backward compatible, by the way. yep! > Idea #3 - veltag: As long as veltag tools don't pollute too much Generic > and View tools! I'm not using it either. not to worry, the tag should use tools just the same as the servlet. > Idea #4 - standalone toolbox: if it's easier for 2.x, ok, but I thought > there already was a patch for it?! there is, but the implementation is a not really what i'm half-thinking about. i'd actually like it to be a little less "standalone" and overlap/serve-as-a-base for the other toolbox support. but i can't really be sure there until i dig into implementing it a little more. > Idea #5 - syntax simplification: it is always great. > > > 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? > > AFAIAC, 2.x is ok. > > > Question #4 - Are there any other "big" ideas out there for a VelocityTools > > 2? > > What about tools pooling ? that's still in the back of my mind. i got pretty far along the path of implementing this a few years ago in a local tree, but it quickly became clear that i couldn't make it B.C. or work for GenericTools without just going to 2.x. i've also been demotivated by the improvements to garbage collection and instantiation of objects in newer JVMs. still, if we're going to work on 2.x, i'm willing to dig up that old code. it should be easier now, especially with idea #2. if/when we get to this, are you willing to help? > Also, do you remember my proposal to have regexp scopes for tools? The > idea was that regexp scopes are thinner than the request scope: tools > are instanciated only if the URL matches the regexp. I'm quite sure that > the performance issue is not that great for compiled regexps. oh, yeah. i totally forgot about that. it's a pretty nifty idea. i'll keep it in mind, so i don't make any changes that would make that really hard to do. but again, it's not a big itch for me. help would be great. :) > Otherwise - VelocityView is a minimal web framework - as such, it deals > with some problematics that are more linked to standard webapp concerns > than to Velocity itself. So my question: To be able to provide a > ready-to-use webapp, should the view tools adress standard web > problematics like validation, authentication, and the like? sorry, but i have no plans to turn VelocityView into a web framework. i'm actually mildly opposed to that; i like using it as just a view layer. there are others that solve the other pieces and integrate with VelocityView just fine. if you or others want to build a framework around the VelocityView layer, that's fine, but i think it'll have to be a separate project. > > 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. :) > > Interesting. > > > Cheers, > > Claude > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
