Agreed, exactly my thoughts.
Auto-trimming == A Good Thing

Does anyone use non-trimmed values on such a massive scale that this 
lack of backwards compatibility would be problem?
I can't thing of any usecases though, except maybe a searchfield or 
something.

-j

Freddy D. wrote:
> Matthew,
> 
>> I also welcome this change.Although I think the default behavior should be
>> reversed...just for consistency and backward compatibility reasons. Granted,
>> I can see this being turned on for a lot of fields, but again there are a
>> handful that I would leave to the current default behavior of not trimming.
> 
> I think there are /many/ more use cases for which you'd want trimming
> rather than not. Don't you think it would be more convenient to only have
> to add @Validate(trim=false) to those (rarer) fields for which you do not
> want to trim, rather than having to add @Validate(trim=true) for all the
> fields that you do want to trim?
> 
> As for backward compatibility, the only problems would be caused for
> applications that need spaces in the input to be preserved. The fix would
> be to add @Validate(trim=false), and that would be documented of course.
> I don't think this would cause many problems; at least not enough to outweigh
> the convenience of trimming by default.
> 
> What do you think?
> 
> Cheers,
> Freddy


-------------------------------------------------------------------------
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

Reply via email to