David,
A few remarks:
- I'm not sure that we should loose the value entered by the user once the
transformation is done. Although I see the argument that once transformed
the string value is most likely redundant, there may be cases when it is
still useful. Also, unless you're able to make the reverse transformation
and produce the exact same string as the user has entered, further display
of the form may confuse a user when the displayed fields differ from what he
has entered. I would be more in favor of an ActionForm that is just a
placeholder for values entered by the user, like it is at present.
- Having only one validator per property is a limitation. We should be able
to have more than one like you already support in your current framework. We
should also think about validation across several fields. For example, in
the application we're working on we have a page where a date is entered via
three different text fields. This introduces the requirement to be able to
validate and transform multiple fields at a time.
To satisfy this requirement we have now a 'Mapper' framework to validate
and transform ActionForm properties. Mainly all we do now is customizing a
configuration file which contains things like (at the lower levels of the
hierarchy):
<mapping>
<source objectName="form" fieldName="day"/>
<source objectName="form" fieldName="month"/>
<source objectName="form" fieldName="year"/>
<dest objectName="commandBean" fieldName="date"/>
<validation skipIfNullOrBlanks="true">
<!-- if at least one source value is not null or
not a blank string the following validation
rules will be applied -->
if (!isDay(source[0])) fail("Invalid day");
if (!isMonth(source[1])) fail("Invalid month");
if (!isYear(source[2])) fail("Invalid year");
</validation>
<!-- if the above validation succeeds, the converter
defined below is invoked -->
<conversion converter="Strings2DateConverter"/>
<transfer/>
</mapping>
Note that we have separated the concept of validation and conversion. While
multiple validators can be invoked on multiple fields at a time (using a
small Java-like language), only one converter is invoked, possibly on
multiple fields, like in the above example. The mapping shown above is a
full one: it contains validation, conversion, and transfer (of the converted
value to the destination). But nothing prevents you from defining mappings
that only contains validation.
Mappers are actually totally independent from Struts, so the framework can
be applied in other types of application for validation and transformation.
The integration with struts is just in two places: in a descendent from the
ActionServlet, where we load the configuration file, and in a descendant
from the ActionForm, where the validate method calls the mapper associated
with the form and produces an ActionError for each validation/transformation
failure.
Fr.
-----Original Message-----
From: David Winterfeldt [mailto:[EMAIL PROTECTED]]
Sent: 14 June 2001 06:32
To: [EMAIL PROTECTED]
Subject: Re: Client/Server Side Validation for Struts 1.1
I just saw the type conversion thread going on in the
user list, but I've thought about this for a bit and
you mentioned possibly modeling or taking code from an
existing framework.
How closely have you looked at Barracuda Ted? Some of
what they do is interesting. I think we could make an
ActionForm derivitive that loosely followed their
steps in processing an object.
Barracuda
-------------
FormMap
FormElement
key - the key/property name
type - the FormType (ie. String, Boolean,
Integer, etc)
defaultVal - the default value (ie. the value to
be used if the key is not present in the form source)
validator - FormValidators responsible for
validating this particular element
allowMultiples - is it possible for this key to
have multiple values in the form source
add these other fields to the field element in the
valdation.xml
public class BarracudaActionForm extends ActionForm {
Map formMap = new HashMap();
public Map getFormMap() { return formMap; }
public void setFormMap(Map formMap) {
this.formMap = formMap;
}
public void reset(ActionMapping mapping,
HttpServletRequest request) {
formMap.clear();
}
}
populate map
perform transformations from map to real objects using
subclasses of java.text.Format as Rey Francois has
suggested, if the transformation was successful remove
the item from the Map. (Struts html tags would need to
be able to try the Map first and then the actual
ActionForm property. This could tie in with a dynamic
ActionForm class)
populate default values
perform other validations
Or we could make a transformation class for the
general transformation package you suggested and you
would pass in any two JavaBeans and it could map
values between the two. Something like this could be
used from a short cut method in the ActionForm.
public Object getDataBean() {
// Class name could come from an xml
transform/mapping file
Object bean =
Class.forName(className).newInstance();
Transformation.transform(this, bean);
return bean;
}
It seems from discussions that most people would
prefer the latter based on current usage on the lists,
but you wouldn't need two classes with the first
approach and it is from a working framework. What is
your opinion?
David
--- Ted Husted <[EMAIL PROTECTED]> wrote:
> I still have the feeling that we lack a decent
> foundation package to do
> the grunt work of typecasting and String formatting,
> so that things like
> a Validation servlet and something like a
> <bean:transform
> picture="##/##/##" > tag could share a common
> codebase.
>
> We might want to start with something like this:
>
> <
>
http://www.mail-archive.com/struts-dev@jakarta.apache.org/msg01522.html
> >
>
> Perhaps as an extension to java.text.Format, as Rey
> Francois has been
> suggesting:
>
> <
>
http://www.mail-archive.com/struts-user@jakarta.apache.org/msg02711.html
> >
>
> And then look at how we can use this package to
> extend the Validation
> servlet and enhance the bean tags.
>
> It's a little confusing now, since validations,
> conversions, and
> transformations and are closely linked, but appear
> at different points
> in the input / store / output continuum. Even so, I
> think the processes
> have enough in common to create a cohesive package,
> even if you would
> not use every method on any one layer of a MVC
> application.
>
>
> -- Ted Husted, Husted dot Com, Fairport NY USA.
> -- Custom Software ~ Technical Services.
> -- Tel 716 737-3463.
> -- http://www.husted.com/about/struts/
__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/
************************************************************************
The information in this email is confidential and is intended solely
for the addressee(s).
Access to this email by anyone else is unauthorised. If you are not
an intended recipient, you must not read, use or disseminate the
information contained in the email.
Any views expressed in this message are those of the individual
sender, except where the sender specifically states them to be
the views of Capco.
http://www.capco.com
***********************************************************************
