Geir said, > On Monday, February 17, 2003, at 09:36 PM, Nathan Bubna wrote: ... > > 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. > > Why? > The point is to have a place for stuff that isn't just for use in > servlets. Doesn't that make sense?
yes, but does that place have to be devoid of servlet-tied stuff? in other words, how does it hurt to have servlet stuff in the same package? basically, at this point, the only non-servlet tools are MathTool, DateTool, and the ToolLoader. beyond that, i can only think of only two more non-web/servlet-tied tools that might go there. this project has been around for over a year now, and i've seen very few proposed or contributed "generic" tools. if we only pull the ParameterParser into the view (the least we should do), then we're maintaining an extra jar and tree for a very small handful of tools. so, i have to wonder if it isn't more work for more people to do it this way, rather than folding the two trees. (more below) ... > > can anyone give a really good reason to maintain a separate library > > just for > > these tools? after all, they are "view tools." > > </nathan> > > I guess we'd have to figure out what a 'view tool' is. I use velocity > in all sorts of places that has nothing to do with a UI, and thus > having a toolset decoupled from a web-oriented view kit is what the > original purpose was for that part of the project. > > I think that you are right taking view-centric or web centric stuff > into the view project, but keeping things clear and decoupled is the > right thing, IMO. theory is great and all, but in practice, "clear and decoupled" is not always best. simplicity and convenience are factors to be considered as well. a balance here would be good. at this point, if we're looking at maintaining three trees/jars for such a young/small project, i really feel that theory has had more consideration than it warrants. ... > > 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> > > How? Don't you need to drag around servlet.jar? huh? if someone downloads a binary of a velocity-tools-view.jar that includes a non-servlet tied MathTool, and they only use that class, why would they need to have servlet.jar? yes, they would need servlet.jar to compile the library right now, but i assume we're headed toward having binary releases at some point. further, even if they really do want to compile the library themselves, we already keep the servlet.jar in CVS. they wouldn't have to drag anything. also, let's talk numbers a bit. how many out there are exclusively using the few generic tools we have in a non-web environment? i'm pretty darn sure that the drastic majority of velocity-tools users are pulled in by the view servlet and/or struts functions. and i find it hard to believe that the theoretical few who are here for generic tools will be very inconvenienced by finding them amongst servlet-tied classes. to really get to it, i might not even be disappointed to see us fold the tools/struts tree in as well. one velocity-tools.jar would be nice... :-) Nathan Bubna [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
