David,
We don't generate any classes yet, but the intention would be to do so for
ActionForms at a later stage.
We would use a separate XML file, because the mapper-config.xml contains
mappings, not bean definitions (mappings define many-to-many relationships
between fields of several objects).
I have of course the source for this mapper framework. If the decision was
only mine I would be pleased to share it. I need to discuss this with other
people within my company who should also be involved in this decision. I
hope to get this sorted out this week...
Are you still exploring solutions for a validation framework?
Fr.
-----Original Message-----
From: David Winterfeldt [mailto:[EMAIL PROTECTED]]
Sent: 15 June 2001 14:31
To: [EMAIL PROTECTED]
Subject: RE: Client/Server Side Validation for Struts 1.1
I just wanted to put this out there to see what people
think since I took the time to look at how Barracuda
worked. I like the idea of not having two classes
(ActionForm and a data bean), but I guess there will
be a few different tools to autogenerate these as time
goes by. Do you autogenerate classes based on the xml
file? You have all the information in the xml file to
make this possible, right? I think most of the issues
you mention could be worked around, but you're Mapper
idea is much more flexible. Is any source for what
you've done available to look at or is it proprietary
(I do have the xml file you sent to the list)?
David
--- Rey Francois <[EMAIL PROTECTED]> wrote:
> 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
>
=== message truncated ===
__________________________________________________
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
***********************************************************************
