On Sun, Jan 3, 2010 at 7:31 PM, Honza Král <[email protected]> wrote:
> Hi everybody,
>
>
> On Fri, Jan 1, 2010 at 10:30 PM, Joseph Kocherhans
> <[email protected]> wrote:
> <snip>
>> The ComplexValidator doesn't know in advance if it's going to be used
>> for model validation or form validation. ComplexValidator's get_value
>> method is meant to help with this situation, but it needs to take
>> *both* the dict and obj values to get the value, and as such, it's a
>> little clunky.
>
> We could change this by instantiating the ComplexValidator with obj
> and all_values (or make it a factory for validator callables, anything
> of that sort), so that custom validation code (currently in __call__)
> would just call .get_value('other_field'). It might be tricky too --
> we would basically be passing classes to the field's validator param,
> instantiating them in form/model.clean() and then calling their
> .validate() method (or __call__ing them), but the interface of the
> code itself would be much less clunky.
>
> We would just need to provide a clean interface for defining such
> validator - haven't really thought about this approach so I don't have
> an API proposal ready.
>
What if we had some sort of wrapper class for objs, it could overide
__getattribute__ to return either an attr if it's an obj, or a
subscript if it's a datadict. it seems to me this would solve both
concerns?
Alex
> <snip>
>> Here are a few options:
>>
>> 1) Drop ComplexValidator support for 1.2.
>>
>> I think we could come up with a more elegant solution given some
>> usage and time. The branch is still incredibly useful even without
>> ComplexValidator.
>
> Sure, we could do this, I am +0 on this. We need real life use cases
> just to be sure if people want these validators.
>
>> 2) Convert a model to a dict before passing it to ComplexValidator
>> so they always just deal with dicts.
>>
>> This wouldn't address my discomfort with isinstance checks, but it
>> would make writing ComplexValidators a lot less clunky.
>
>
> I am -1 on this since it wouldn't allow people to call methods and
> properties on their models from their validators if they wanted to.
>
>
>>
>> 3) Leave ComplexValidator in as-is.
>>
>> I don't need a whole lot of convincing that this is the way to go.
>> If we come up with a better solution later, ComplexValidator itself
>> would be fairly easy to deprecate.
>
>
> I would like to invite Jacob and Malcolm into this discussion since the API
>
> def my_validator(value, all_values={}, obj=None):
> ...
>
> was initially their idea during DjangoCon 2008 and they had some
> persuasive arguments there.
>
> I decided not to make all validators have this signature to keep the
> option of using a Field without a Form or Model, that's where the need
> to separate these two types of validators arose.
>
>
>> 4) You're awesome idea that has escaped me so far.
>>
>> This will probably start with option 1, then we'd add the feature
>> after the branch is merged, or in the 1.3 timeline.
>
> definitely +1
>
> --
>
> You received this message because you are subscribed to the Google Groups
> "Django developers" 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/django-developers?hl=en.
>
>
>
--
"I disapprove of what you say, but I will defend to the death your
right to say it." -- Voltaire
"The people's good is the highest law." -- Cicero
"Code can always be simpler than you think, but never as simple as you
want" -- Me
--
You received this message because you are subscribed to the Google Groups
"Django developers" 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/django-developers?hl=en.
