tapestry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brian K. Wallace" <br...@transmorphix.com>
Subject Re: Thoughts on TAPESTRY-197
Date Thu, 09 Mar 2006 00:18:16 GMT
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On this one, I'm of the opinion that fixing it in the base abstract
(BaseValidator) is the right course. Although I'd also be of the opinion
that having a "should trim" property that can be set to false/true
(defaulting to true) would be right, too. My only real concern is the
change of the concrete implementation's public method (although that may
not be as big an issue as I'm trying to make of it)

As for the help - not a problem.

Brian

Jesse Kuhnert wrote:
> Whatever the outcome (don't have time to look into the details of this one
> right now), you're help on everything is very very much appreciated. So,
> thank you :)
> 
> jesse
> 
> On 3/8/06, Brian K. Wallace <brian@transmorphix.com> wrote:
>   This issue deals with input parameters being trimmed as specified in
> IValidator. A comment by Howard on 3 May 05 advises against trimming
> getParameter() instead performing the trimming inside ValidField or
> AbstractTextField. The issue with those are that they are abstract
> classes which do not deal with the IValidator's toObject method (they
> don't even implement IValidator).
> 
>   The only way I see to 'fix' this issue is to go into each validator
> (DateValidator, EmailValidator, IntValidator, NumberValidator, etc...)
> and trim inside their toObject methods individually - or - go into
> BaseValidator, implement a toObject that performs the trim, then calls
> an abstract method of the same basic signature for subclasses to
> implement (instead of having all subclasses implement toObject, they
> would be changed to implement the new abstract method).
> 
>   The only other possibility is to change the documentation of the
> IValidator interface to state "input will NOT be trimmed" - then all
> current validators will work as the javadoc states. I, personally, think
> input should be trimmed by default and am willing to make the changes
> necessary - but that toObject method is public and changing its
> implementation to a superclass could have wider ramifications than I can
> envision.
> 
> Thoughts?
> 
> Note: This issue is written against 3.0, but the same condition exists
> in trunk.
> 
> Brian
>>
- ---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFED3RIaCoPKRow/gARAoenAKDWOixYWlOZo40qRcAkWkTtTmz74ACg8oDU
fIs4cExrK1Q4BiRdsykB+FE=
=/Fd1
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org


Mime
View raw message