+1 (default trimmed)
________________________________________
From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Ben Gunter [EMAIL
PROTECTED]
Sent: Thursday, May 01, 2008 4:07 PM
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
-------------------------------------------------------------------------
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
