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/
