Alberto Valverde wrote:
> Wow... I think this is too much hassle for what it's worth IMO,
> remember this problem *only* appears when a Schema overrides a field
> validator with a validator that differs in it's from_python method.
>
> It's not needed really because the only use of validator overriding
> (I've found myself) is for things that only affect the input and do
> not change the from_python method. A field for phone number won't
> become, a credit card field in the next form, for example. What
> basically needs to be overriden is:
>
> 1) init params for a validator ('min', 'max', maybe a regexp,
> not_empty, if_emprty, etc...)
> 2) Different fancy lookups in database to avoid duplicates, confirm
> existence... for things like an email field, username, etc..
>
> ...
>
> I've never found a use-case use for something that would affect
> from_python, which is the only method you need to trust from
> self.validator in update_data. At validate you can always trust the
> validator because the metaclass has taken care of updating it. If you
> can't trust it at update_data there is a bug in your program, which
> is possibly related to a careless override ;)
>
Agreed on everything, thanks for providing some real use cases. :-)
>
> Who would want to do this? Remember SelectionField (which is of the
> few which need a validator at update_data) already tries to guess a
> correct validator if none is given at the widget.
I know that SelectionField guess a validator, but this is not related
to passing totally different options at display time (the guess only
happens at init time) but as I've said this is a dumb example and only
someone crazy could try to do something like this, so there is no
problem as you also said... ;-)
>
> Then you don't really need a Schema for them, so you're problem is
> gone :) Schemas are only really needed for *input* at
> FormFieldsContainers.
In fact I said we should probably remove the validator from Widget and
CompoundWidget and just use it for InputWidget...
>
> You can try a custom descriptor that stored state somewhere at
> cp.request as you seem to like this path a lot :D
No, the contrary I don't like the path and I don't want to put any
other thing there now and never. :-)
>
> Well, my bottom line is that you can always trust the widget's
> validator at update_data. Overriding at Schema should be done in a
> "know-what-you're-doing" fashion, that means making sure you use a
> "compatible" validator for overridng, that is, they're from_python
> methods are equivalent.
>
Agreed, let's keep things as they are ATM and just use the patch for
is_required.
Thanks for pointing these things out! ;-)
Ciao
Michele
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"TurboGears Trunk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/turbogears-trunk
-~----------~----~----~----~------~----~------~--~---
