Hello Christian. My answer would be that in "1.00@0,55" we would leave it
as is and filter it. If after the filter (when it is in the format WE need)
we could not validate it, than its not valid. The power must rely in the
filter because WE, ABSOLUTELY, NEED TO VALIDATE IN OUR FORMAT. Therfore the
filter must know about "@" characters etc.
----- Original Message -----
From: "Christian Cryder" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>; "Jonathan Asbell" <[EMAIL PROTECTED]>
Sent: Tuesday, June 19, 2001 11:12 AM
Subject: RE: Client/Server Side Validation for Struts 1.1
> Hi Jonathan,
>
> Interesting question, and one we're still wrestling with in Barracuda too.
I
> see one possible problem with filtering then validating.
>
> Using your example below, what happens if the Brasilian values looks like
> this:
> 1.00@0,55
> The problem now becomes "how do we filter something that is invalid?" Do
we
> silently suppress the invalid @ character because we don't know what it
is?
> Or do we just leave it alone? Or what about something like this:
> 1.00,05,5
> Which comma is the real one?
>
> The essence of filtering is that you are changing things that the user
> entered to get them into a format that the software can understand (ie
> Floats). In many cases, we can safely guess user intent, but in others it
> becomes much more difficult. For instance, lets say I'm accepting a whole
> dollar bid on an item (ie. no decimal points). What if the user enters
> 10.00? If my filter tries to guess intent and silently skips the decimal
> since its not a valid character for this value, it could conceivably
convert
> my ten dollar bid into a thousand dollar bid (by dropping the decimal).
> Since the result of the filtering is a valid number, processing continues
> and the bid is placed (and in many cases the user might not even realize
> what just happened).
>
> Granted this is a contrived example, but I think it illustrates one of the
> pitfalls of filtering. To be safe, any time you filter/adjust a value, you
> really want to give the user a chance to verify that the adjustment you
made
> is correct. Often, however, that type of "hey is this what you meant?"
isn't
> real conducive to the app workflow.
>
> Just some food for thought...
> Christian
> ------------------------------------------------
> Christian Cryder [[EMAIL PROTECTED]]
> Barracuda - MVC Component Framework for Webapps
> http://barracuda.enhydra.org
> ------------------------------------------------
> "What a great time to be a Geek"
>
>
> > -----Original Message-----
> > From: Jonathan Asbell [mailto:[EMAIL PROTECTED]]
> > Sent: Tuesday, June 19, 2001 6:20 AM
> > To: [EMAIL PROTECTED]
> > Subject: Re: Client/Server Side Validation for Struts 1.1
> >
> >
> > This is what I'm saying. Lets not use your social security number as an
> > example because it is only for the USA. Lets use money. In the
> > USA we use
> > 1,000.55 for one-thousand-fifty-five dolars. In Brasil they use
1.000,55.
> > We would allow a user who lives in Brasil who also chose to view
> > content in
> > Portuguese to enter the number the way THEY understand. WE, on the
other
> > hand will have built a filter to change what they entered into the
format
> > which we work with (1,000.55 ) to validate it. This means ONE
validation
> > created for money, but a filter had to be created for users located in
> > Brasil. The filter just changed their format to the format we need to
> > process. When we decide to give this capability to another
> > location/language
> > we jjust create a filter and use the same validator. Of course the
filter
> > would have to work going TO the application from the presentation and
from
> > the application back to the presentation.
> >
> > If not, you have to do validations for a zillion different permutations
of
> > possibilities
> >
> > What do you think?
> >
> > ----- Original Message -----
> > From: "David Winterfeldt" <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>; "Jonathan Asbell"
> > <[EMAIL PROTECTED]>
> > Sent: Monday, June 18, 2001 11:01 PM
> > Subject: Re: Client/Server Side Validation for Struts 1.1
> >
> >
> > > 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/
> > >
> >
>
