+ @Validate(trim=true - by default
Ruslan
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Ben
Gunter
Sent: May 1, 2008 10:08 AM
To: Stripes Users List
Subject: [Stripes-users] Need feedback
Hello, folks. The subject of trimming parameter values before
validation, type conversion and binding has come up many times on this
mailing list, and we have had several lengthy discussions about it on
IRC as well. We need to make a decision about how to handle it, and we
want to see how everybody feels about it before we commit one way or the
other.
What we're thinking is that all parameters will be trimmed by default
during validation, type conversion and binding. This means any values
bound into an ActionBean will be trimmed first. All validations
(required, maxlength, minlength, etc.) will also be applied to the
trimmed value. However, values returned by
ServletRequest.getParameter(..), getParameterValues(..),
getParameterMap() and any others I've missed will return the value
exactly as it was submitted in the request.
We will add @Validate(trim={true|false}) to allow you to disable this
behavior and use the untrimmed value. The default value for "trim" will
be true, and if you explicitly set it to true then the behavior will not
change. If you explicitly set it to false, then the value will not be
trimmed.
Since the question has come up many times, I will explain the minor
complication we must consider for @Validate(trim=..). Annotation element
value types are limited to primitives, Class, String, Enum and
one-dimensional arrays thereof. Boolean is not a valid option for the
type of "trim." The effect of that limitation in this case is that we
cannot have "trim" as a boolean and allow a global option to enable or
disable trimming by default. Each @Validate will have a value for "trim"
whether or not "trim" is explicitly set, and that value will be either
true or false. We cannot determine at runtime if that value is true
because it was not specified (and therefore assumed the default value)
or because it was explicitly set true. So if we allowed a global option
that turns off trimming, then every @Validate that didn't specify the
"trim" element would override that default value. We are aware that we
can define a new enum that specifies TRUE, FALSE and DEFAULT, but we're
not too keen on that approach.
All this rambling has been leading up to this question: How do you all
feel about values being trimmed by default with exceptions being allowed
for specific fields by setting @Validate(trim=false)? This change will
affect backward compatibility in some cases, but we believe those cases
to be rare. Does anyone have a use case where this would cause them a
lot of trouble? Speak now or forever hold your peace.
-Ben
***************************************************************************************************
The information in this email is confidential and may be legally privileged.
Access to this email by anyone other than the intended addressee is
unauthorized. If you are not the intended recipient of this message, any
review, disclosure, copying, distribution, retention, or any action taken or
omitted to be taken in reliance on it is prohibited and may be unlawful. If you
are not the intended recipient, please reply to or forward a copy of this
message to the sender and delete the message, any attachments, and any copies
thereof from your system.
***************************************************************************************************
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Stripes-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/stripes-users
