Hi Ben
Autotrimming seems like the most reasonable default. +1 from me.
/Jeppe
On 01/05/2008, at 16.07, Ben Gunter wrote:
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
-------------------------------------------------------------------------
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
-------------------------------------------------------------------------
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
