+1 default: trim = true
On Thu, May 1, 2008 at 7:07 AM, Ben Gunter <[EMAIL PROTECTED]> 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
