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
