commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John McNally <jmcna...@collab.net>
Subject turbine vs. struts validation framework
Date Tue, 08 Jan 2002 20:05:32 GMT
When I started work on Intake, I did a survey of struts and commons and
did not find anything had been implemented.  Soon after (within a couple
weeks to a month) I had intake functionally complete enough to be of
use, I noticed David's validation framework began being discussed on the
struts list.  I looked at it as a possible alternative, but it appeared
to be tied to Struts api, and since we already had intake, i discounted
its use in turbine.

A couple issues I had with the David's code was:

1.  It appeared necessary to specify every form field within an xml
file.  If a field appeared on a couple different forms it would be
necessary to add it multiple times with the same information.  There was
possibly some shorthand, but it still seemed you would need to have xml
describing every form in your app.

2.  The validation framework integrated an internationalized message
formating framework.  While internationalized validation of inputs is
good and I think struts framework is probably better than intake on this
score), adding in the error message internationalization seemed overly
complicated and can be handled better by a localization specific
framework.

Now both these criticisms are based on a quick look at the code
approximately a year ago, just giving my reasoning for not jumping on
the struts validation framework, instead of sticking with what i wrote.

As the two frameworks approach the problem from slightly different
perspectives, they will appeal probably to different users.  I really do
not want to get into a war about which is better.

About moving intake into the commons.  I have stayed away from
interacting with the commons project as it was described by many as a
hornet's nest where everything requires considerable argument to get
anything done.  And often nothing

A particular reason for not moving intake here was my possible
misconception that the commons was a place for components that did not
require configuration using properties files, xml, etc.  I am sure I
read that somewhere when the commons was created.  As David's validation
framework requires the use of configuration xml, I guess this
restriction has been removed, or my memory is wrong.  Intake uses an xml
file to specify the constraints on the inputs.  

Intake uses the service framework known as fulcrum.  I guess I can take
a look at extracting it from dependencies on fulcrum.

john mcnally

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message