Hmm. There are also special, default validators for checking the type of the input parameters. Validation is done before the actual type conversion. _________________________________________________ Is it not easier to make the conversion first and then the validation? If I 'deserialize' a string to object (some entity based on some key-string for example) I want that object in my validator and not the stringvalue. So I would find it better if you first convert then validate the value and then assign the value.
I can see how you would want this, as it is yet another abstraction from the http protocol. The current validators are close to the http protocol, as they use strings as parameters. --------------------------------------------------------------- What is the advantage? And if you want the keep the option you could do: HttpAttributeValidate Transform Validate Assign. But I don`t know why you should want to use it. The problem is though that we give yet another method of validating, and we have to take the order of validations in consideration. If a string can't be converted to a integer, should we still call the other validators? Currently that is done, but what to do with the typesafe validators? ----------------------------------------------------------------- I think you should skip validation as soon as an error occurs. Further validation won`t make a lot of sense. I'm not sure this is a very great idea, but if there are more people +1, then I'm not against. More provoters please! Martijn Peter Veentjer - Anchor Men wrote: >The validators are all based on strings. I would rather have a validator that >accepts arguments of the right type and the string value`s shouldn`t be >transformer more than once.. > >so: >transform to right type >validate >assign. > >________________________________ > >From: [EMAIL PROTECTED] on behalf of Eelco Hillenius >Sent: Mon 18-7-2005 21:12 >To: [email protected] >Subject: Re: [Wicket-user] why such a strange design in the AbstractValidator > > > >I agree that's an improvement. It's less elegant that we have all those >methods carrying the instance of FormComponent now, but it is better to >have validators thread safe by default. > >If we're going to change this, it will mean an API break for a lot of >clients, so this will be 1.1 only. And while we're at it, let's see if >we can improve the validation part further. Phil just filed this: >https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1240458&group_id=119783 >with which I also agree. > >Do other people have votes/ idea's on this? > >Eelco > > >------------------------------------------------------- >SF.Net email is sponsored by: Discover Easy Linux Migration Strategies >from IBM. Find simple to follow Roadmaps, straightforward articles, >informative Webcasts and more! Get everything you need to get up to >speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click >_______________________________________________ >Wicket-user mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > > ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
<<winmail.dat>>
