What do you mean by "converted into the format of the
system"? Do you mean the object and not the String
representation in the ActionForm? Or are you refering
to the part where I talk about associating a locale to
a phone number?
Expand on what you were saying if this doesn't cover
it, but the initial validations would be to get
required fields filled in and in the correct format to
be converted to objects. For example, there would be
no reason to check that a social security number is in
your system until it is a well formed social security
number. Then you can convert your ActionForm to a
JavaBean with correct java types (java.util.Date,
etc.) and with the typed JavaBean you can then pass
that to a validation bean, an EJB, or any other server
side resource. And if you have a multi-tier
distributed system you would ideally want to get the
information filled in properly before you send it to
an EJB.
Or if you mean that there are a lot of permutations
for phone numbers or dates, there are. If we model
things to take a pattern (MM/dd/yyyy or (###)
###-####), then one type of class can perform the
validation/conversion based on the pattern. A date
can get converted to a date for checking if it falls
in a range, is within the last seven days, etc., but a
phone number is phone number and can't really be
converted into a standard format like a date.
David
--- Jonathan Asbell <[EMAIL PROTECTED]> wrote:
> Hi Dave. I really think (and tell me what you
> think) that all special
> formatting shoudl eventually be converted into the
> format of the system it
> is running on, THEN validated. Otherwise you have
> to design a gazillion
> permutations to validate. We could instead make
> various converters for each
> situation as needed, and one central validation
> package.
>
> ----- Original Message -----
> From: "David Winterfeldt" <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Monday, June 18, 2001 2:26 PM
> Subject: RE: Client/Server Side Validation for
> Struts 1.1
>
>
> > 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
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/
