Hey Nathan, Glad you pulled this stuff out, I hadn't seen it.
+1 --- Nathan Bubna <[EMAIL PROTECTED]> wrote: > Ok, since the original proposal i made for this was rather buried in > a > separate conversation, i want to give this proposal a thread of its > own > before i take action on it. > --------------------------------------------- > The gist of the proposal is this: > > Move the generic (i.e. non-struts) tools from the tools/tools > package > into the tools/view package and drop the tools/tools package > altogether. > > The new package designation for these tools would be: > org.apache.velocity.tools.view.tools.* > > One thing not mentioned as yet: I'd also like to move the > MultiViewsTool > from org.apache.velocity.tools.view.i18n.* to > org.apache.velocity.tools.view.tools.i18n.*. I think that would be a > more > consistent organization. Daniel, does that work for you? > --------------------------------------------- > So far the responses are: > - Committers in favor: Nathan > - Contributors in favor: Tim Colson > - Ambivalent or Opposed: none > --------------------------------------------- > For those wondering why this has been proposed here's a recap of the > discussion so far: > > <nathan> > you know, as i think about it, i'm not really sure why we even have a > separate folder tree/jar/et. al. for the non-struts tools. there's > all of > three useful classes in there, and one of them is already dependent > on the > view package. i'm seriously thinking we ought to fold them into the > view > tree/package. i think it'd be nice to cut things down to just > VelocityView > and VelocityStruts (or whatever you want to call them). > > can anyone give a really good reason to maintain a separate library > just for > these tools? after all, they are "view tools." > </nathan> > > <tim> > Aren't the tools supposed to be able to live without > VelocityViewServlet, so folks using other frameworks can leverage > them > without the extra baggage? > </tim> > > <nathan> > yes, that's the idea. but as i said, one of the four tools in there > (ParameterParser) is already dependent on the view package (the home > of the > VVS). so, if they want to compile the tools library or use the > ParameterParser, they already need the view package. so what's the > harm in > combining the two? if they don't want to use the servlet-tied stuff, > then > they can just ignore it and use only the tools they want. > </nathan> > > I'll probably give this a week or so, and if there's still no > opposition, > i'll start making the switch. I really think this is a good move to > simplify things. > > Nathan Bubna > [EMAIL PROTECTED] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > __________________________________________________ Do you Yahoo!? Yahoo! Shopping - Send Flowers for Valentine's Day http://shopping.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
