I'm one of those against extra dependencies. As I said in the mailing list previously (see http://sourceforge.net/mailarchive/message.php?msg_id=3757306 regarding your question on JELLY dependency!) every dependency adds extra complexity. Formproc, in particular, means adding configuration to an extra location. XWork and WW config can be merged together (a WW config would include the accompanying XW config), and requiring formproc means we have a minimum of two config files... in one product. Bad, especially when we can do it ourselves.
Why do you keep wanting to tie WebWork to other projects so badly? This is the second time I've seen you wish for extra dependency (the url above was expressing your desire for using JEXL as core WebWork, and your message now is for FormProc for form validation...) On Fri, 14 Feb 2003, Kelvin Tan wrote: > Are we being a little paranoid about not introducing "another dependency"? (can > one be too paranoid about this? :-) > > What is the real concern here? That we're potentially introducing an additional > point of instability, that we're increasing the download size of the framework, > that we're creating unnecessary overhead, or that we think we can implement > some things better/faster/etc/etc. I guess the fact that we choose to implement > internally suggests that we believe we can up with something better? > > I don't have any one in mind. I'm just interested to know the rationale behind > the decision. I guess coz I'm new to this community, still trying to get a feel > of how things work, esp behind the scenes. :-) > > > On Thu, 13 Feb 2003 20:13:14 -0800, Jason Carreira said: > >The argument was that we did not want to introduce another > >dependency. I was actually arguing FOR FormProc, but the feeling was > >that we wanted to keep the required dependencies to a minimum. The > >main thing I was looking for in FormProc were the localized and > >parameterized messages, which turned out to be relatively easy to > >implement, and the ability to define scripts for validation. I'm > >currently thinking about adding another type of Validator, which is > >not tied to one particular field, and I'm thinking the first > >implementation would be one which uses Ognl to evaluate the > >expression you give it. Since Ognl can be used for basically > >ANYTHING, including defining lambda expressions, this should easily > >handle this requirement as well. By looking at the current > >ValidationInterceptor, however, it should be relatively easy to see > >how to plug another validation framework into Xwork, and I'd be > >happy to help you if you want to do that. Which framework were you > >thinking of? > > > > > > ------------------------------------------------------- > This SF.NET email is sponsored by: FREE SSL Guide from Thawte > are you planning your Web Server Security? Click here to get a FREE > Thawte SSL guide and find the answers to all your SSL security issues. > http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en > _______________________________________________ > Opensymphony-webwork mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork > --------------------------------------------------------- Joseph B. Ottinger [EMAIL PROTECTED] http://enigmastation.com IT Consultant ------------------------------------------------------- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
