I've still been continuing work on the Struts
Validator (http://home.earthlink.net/~dwinterfeldt/)
in it's present form, but I've been thinking about the
discussion under this thread and the best way to
integrate these ideas with what I've done so far. It
seems like it is best to keep everything as separate
components and just make sure they work together. The
Mapper is separate. There should be a general
validation/transformation package that you can pass in
a String and it can create on object for you and throw
an Exception if it can't (based on java.text.Format as
you suggested). This package could then be used for
the Mapper, validation, and formatting. So you should
be able to define that a date should be "MM/dd/yyyy"
and this would be used for formatting of the date
object as it is converted to a String in the
ActionForm and also would be used for validation and
after validation for the transformation back to a date
object. But as it was discussed, the way the standard
message resources work (from a region down to a
language) doesn't make sense for a phone number that
should be associated with region and has nothing to do
with the language. I was thinking that if resources
like phone numbers were loaded based on a location and
you could reference them from the validation.xml that
might work.
<field property="phone"
depends="mask">
<var name="mask" value="${trans:US_phone}"/>
<arg0 key="registrationForm.phone.displayname"/>
</field>
The 'trans' prefix would represent that the value
should be retreived from the transformation resources
for the US phone number format. Or possibly if you
don't specify a country it would use the one from the
locale in session scope.
David
--- Rey Francois <[EMAIL PROTECTED]> wrote:
> 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
> > {
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/
