I don't think you should filter out unexpected
characters. Java NumberFormat can let you handle how
someone from a locale would enter a number and then
convert it to a float or double.
USA we use 1,000.55 dollars.
#,###.##
Brasil they use 1.000,55
#.###,##
I think you should make the use put in a good value
(of course it is always up to the developer). If some
leaned on the keyboard and put in
"3dddddddddddddddd.44", I would not want to assume
that it is 3.44. And when you get into currency you
may have a minimum of $10 US dollars or 20,000 Lira so
I'm not sure how it helps to get them into the same
format except to save it, do a currency conversion, or
validate on rules for each currency. It is a
complicated issue. I always thought it was best to
save the amount, the currency, and the date so you can
calculate currency conversions if you need to, but
preserve the original user data for future
reference/calculations.
David
--- Jonathan <[EMAIL PROTECTED]> wrote:
> 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
>
=== message truncated ===
__________________________________________________
Do You Yahoo!?
Spot the hottest trends in music, movies, and more.
http://buzz.yahoo.com/
