On Thu, 2006-04-27 at 09:19 -0700, Jason Davies wrote:
>
> > A solution that fits all needs would be to create an extra parameter for
> > these validators (the ones that take field names) that indicates that
> > only fields for this class should be considered (e.g. only things that
> > start with model.__name__, in effect) and the dotted bits
> > ("model.position.") should be stripped before comparison. But that
> > removes the ability to differentiate between client.0... and
> > client.1...; not sure if that is a real problem or not at the moment.
> > Fixing this latter case is not completely trivial, because validating
> > form input does not know about models or edit_inlines or anything:
> > everything is just a bunch of strings at that point.
>
> How about passing an optional name_prefix parameter to these
> validators, which would allow them to look up things like
> all_data[name_prefix + other_field_name]? name_prefix would be
> something like 'foo.0.' or 'foo.1.' when edit_inline is used.
I do not think it makes any difference whether you do it in the thing
calling the validator or in the validator itself. The thing calling the
validator still doesn't know anything about models or any semantics, it
just works with strings. So all you can do is look at the string and say
"hey, this is a string, followed by a dot followed by a digit followed
by a dot. I should strip it". Might as well put that inside the
validator if it is wanted.
What you can't do is determine "now I am processing the model with
edit_inline" set, because it is only working with strings.
So I think your solution is exactly the same as the one I suggest above,
just triggered from a different place. It seems harder to set up the
calling section (your method) to pass in the optional name parameter,
too, rather than setting the option on the validator. But maybe I'm
missing something.
Also, whatever is the "right" solution here has to be reasonably
straightforward for people implementing their own validators. I think
"straightforward" is going to have to mean "really well documented", but
that is kind of why I'm asking for suggestions: maybe there is a cute,
clever solution and I'm not bright enough to see it.
Thanks for the input anyway; it's something more to think about.
Regards,
Malcolm
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers
-~----------~----~----~----~------~----~------~--~---
