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..
>
> The real problem is that having a flying validator means that there is
> no way a widget can trust self.validator as being correct, this means
> we can just remove it at this point, a widget will never be sure at
> 100% of self.validator as being right hence it should not use it, not
> in adjust_value not in any other way.
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 ;)
>
> To make a real example (as you've made), a SelectionField widget
> requires a trusted validator to use, this example will not work in any
> way:
>
> class MySchema(Schema):
> options = String()
>
> class MyFields(...):
> options = SingleSelectionField(options=[(1, "Java"), (2,
> "Python")], validator=Int())
>
> form = TableForm(fields=MyFields(), validator=MySchema())
>
> since you changed the validator you will change options, if you the
> use
> something like:
>
> options = [('One', 'Hello'), ('Two', 'ByeBye')]
>
> the widget will not maintain values on form redisplay since it's using
> the Int() validator and not the String() one.
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.
>
> Another way to solve it and reusing widgets instance could be this:
> - validator is used only for InputWidgets (it makes sense IMHO)
> - we find a way to make self.validator a property that can use the
> path
> (since an InputWiget has it) to retrieve on the fly it's validator
> from
> the root widget (has I've done with is_required).
Too much hassle and unneeded complication IMHO.
>
> this also makes sense since it's true that you could need the to/from
> python work of a validator even for widget that aren't form fields
> like
> an AjaxGrid, but you don't need the to_python thing (no input coming)
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.
> and for the from_python what you want is just the conversion to a
> string (everything is a string on the web) or some other fancy feature
> that you can easily do inside update_data without the need to learn
> how
> to use FancyValidator.
>
> If someone has a solution to make (self.validator) a property that
> doesn't end-up in a infinite recursion and is good with avoiding the
> use of validator for widgets not related to input (this makes a lot of
> sense IMHO and will again simplify things a lot for the use of widgets
> outside of a form) we can use that and all problems are solved. ;-)
You can try a custom descriptor that stored state somewhere at
cp.request as you seem to like this path a lot :D
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.
Alberto
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
