I'm all for it and for the default being true. Even the back-comp issues would be minimal. Deployed working apps probably won't update their Stripes version unless devs just think they NEED a Stripes 1.5 feature. Apps currently being developed and moved to 1.5 would be the only real issue, but as long as its documented I think the effect is minimal still.
So +1 for this feature. Gregg Matthew Altman wrote: > Yes, I agree there will certainly be more cases that would require > auto-trimming than not. And for that reason, it makes sense to make it > the default. > I was just speaking of backwards compatibility and not having to > modify previous code to get it to work. Granted, it wouldn't be > difficult to accomplish. I'm just sort of thinking out loud. > > > On Thu, May 1, 2008 at 10:10 AM, Jasper Fontaine > <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>> wrote: > > 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] > <mailto:[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 > ------------------------------------------------------------------------- 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
