On Fri, 25 Feb 2005 16:57:34 +0000, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Nathan said: > BrowserSnifferTool: > this is my least favorite of the three. the biggest reason being > that it uses Java 1.4's regex stuff, which means we're now dependent on > Java 1.4. on one level, i'm ok with that. after all, there is a > newer version of java out, and 1.4 has a lot of good stuff. the > problem i see is that Velocity itself has not yet required users to move > to 1.4. this bothers me quite a bit, enough, in fact, that i think we need > to retract this tool and put it in the wiki for now. > but i don't just want to veto it without some discussion. > > I don't agree - "VelocityTools" as a whole is not dependent on Java v1.4 - > just the tool, if you don't have Java v1.4 or newer, don't use this > particular tool :-) OTH. if you like to roll your own joint you now need at > least Java v1.4 - but I don't think that's too much to ask in that case ;-)
that's a good point. i guess i won't object, as long as you're willing to maintain the tool. :) i don't anticipate ever using it myself though. i don't much believe in browser detection. > Nathan said: > EscapeTool: > my only hesitation here is also due to dependencies. i'm not > thrilled about adding commons-lang as a dep for just this tool. > especially when you could actually just put an instance of StringEscapeUtils > into the context. but i do see the use in having a simplified interface > to it along with a few other useful little things. and this tool does > appear to be well-used by people. so what do ya'll think? is it worth > another dependency? if most people are in favor of it, i'm ok with > adding it for 1.2. > > All the StringEscapeUtils methods are static and it's stated clearly that > instances should *not* be constructed. I had the same reservations about > adding the dependency - but the tool is useful, and the dependency is > relatively harmless IMHO ... and Shinobu has been so prolific for the past > few months - I thought he deserved it ;) yeah, the compile vs. use argument works for this dependency too, i guess. :) we may soon need to add some documentation page on what dependencies are required for what tools. otherwise confusion or mass inclusion of all dependencies will follow... > Nathan said: > ArrayTool: > this can be very useful and doesn't add any dependencies. however, > its functionality is stuff on my wishlist for the core. and deep down, i > fear that adding it to Tools will lower the likelihood someone will get > enough of an "itch" to patch the core. (and by all that, i mean making > arrays and Lists indistinguishable to a template author). > hmm. i wonder if that means we should make the ArrayTool > transparently handle Lists and arrays the same, as a kind of demonstration > for what the core should do (albeit with different syntax). anyway, i've > pretty much decided i would add this tool, i just haven't gotten > around to it. :) > > I haven't taken a look at this tool yet :P > > cheers, > Marin� > --------------------------------------------------------------------- > 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] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
