Hi everybody,
On Fri, Jan 1, 2010 at 10:30 PM, Joseph Kocherhans
<jkocherh...@gmail.com> 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.
<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 django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
