David Winterfeldt wrote:
> I think it would be good to get a list together of all
> the basic validations we would want to do. I normally
> want to do validations based on the database field the
> bean field corresponds to and basic things like phone
> numbers, zip codes, etc. Is the date validation you
> made i18n?
My date validation was just for the credit card expry date (after
today), but we would obviously want something that was i18n and could
adjust for the user's locale.
Can anyone suggest an existing package, for any platform, that covers
this ground? We might be able to use it for a punch list and to model
the high-level requirements.
I wandered around in the Barracuda source last night, and they have a
nice object for handling conversions between first class types
(org.enhydra.barracuda.core.forms.FormElement), and a base validator
object (DefaultFormValidator) for plugging in whatever validators you
need.
Offhand, I would lean toward keeping our base objects as close to
Barracuda's as we can, and look toward another mature product for other
coding conventions, like the meta-language for expressing the target
format (the "(###) ###-####)" part ).
> I like the idea of a transformation package a lot. I
> think it would be good if it were separate. I've read
> the other thread. If all the fields for a form were
> specified in the XML file even if they didn't need to
> be validated, the "XML --> ActionForm Code Generator"
> on the To Do list could use the validation.xml to
> generate the ActionForm (of course it would have to be
> smart enough to handle nested properties).
Speaking of code generation, here's another idea.
What about a stub code generator that started with the model/application
properties. Then we could also generate a SQL DDL, along with the
ActionForm bean and several other core objects.
So, we would input (via XML or a Web interface) the property/column
name, Java type, [JDBC type,] and whether the property was a database
column, used on a form, used on a read-only view, or used on a list
(master/detail pattern).
Depending on the choices, the code generator could then output a Java
SQL DDL (for creating the database), a plain JavaBean, an object value
bean (non-mutable, bulk constructor), Struts HTML form, Struts HTML page
(read only via bean:write), Struts HTML result page (multiple rows,
links to an Action), Struts ActionForm bean (or ValidatorForm bean),
Struts data access Action, data access Result bean, and relevant
sections of the Struts configuration file (and validation.xml file).
The skeleton for some of these objects could come from the Strut by
Strut article (just updated, if anyone wants to peak).
For this to be most useful, it would have to handle the data conversions
and transformations, which again leads back to the base
transformation/validation package.
If we were clever, we'd write this code generator so that it could be
used in other environments. Something that just generated a Java
SQL DDL, JavaBean, value object bean, and HTML form page, would also
seem generally useful.
Perhaps we should join the two, and look at one package called say
"tonic", with a base transformation/validation object, and a XML-to-Java
object generator that would use the base t/v object to work its magic.
Which again would be good Commons fodder.
-- Ted Husted, Husted dot Com, Fairport NY USA.
-- Custom Software ~ Technical Services.
-- Tel 716 737-3463.
-- http://www.husted.com/about/struts/
