On Feb 19, 12:49 am, Malcolm Tredinnick
wrote:
> On Wed, 2009-02-18 at 04:28 -0800, mrts wrote:
> > The old Field.default_error_messages dict and corresponding
> > logic is no longer required (and removed in my branch) as default
> > error messages live in core/validators now.
>
> It *is* still r
On Wed, 2009-02-18 at 04:28 -0800, mrts wrote:
> The last unsolved model-validation design issue is the error message
> protocol (my work on fields is waiting on it).
Well, it's the the last issue, but it's certainly a stumbling block.
I've been spending quite a lot of time lately trying to merg
On Feb 18, 8:03 pm, Honza Král wrote:
> Hi,
> see inline text.
>
> On Wed, Feb 18, 2009 at 1:28 PM, mrts wrote:
>
> > The last unsolved model-validation design issue is the error message
> > protocol (my work on fields is waiting on it). Let me present the
> > approach that looks sane to me.
>
>
Hi,
see inline text.
On Wed, Feb 18, 2009 at 1:28 PM, mrts wrote:
>
> The last unsolved model-validation design issue is the error message
> protocol (my work on fields is waiting on it). Let me present the
> approach that looks sane to me.
>
> The old Field.default_error_messages dict and corre
On Feb 18, 2:28 pm, mrts wrote:
> def validate(self, value, all_values={}, form_instance=None):
That should have been
def validate(self, value, all_values={}):
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
The last unsolved model-validation design issue is the error message
protocol (my work on fields is waiting on it). Let me present the
approach that looks sane to me.
The old Field.default_error_messages dict and corresponding
logic is no longer required (and removed in my branch) as default
erro
On Sat, 2009-01-24 at 14:13 -0800, mrts wrote:
> After several discussions with Honza, we are still on somewhat
> different positions what the validator function signature should
> be and how core validators should access the fields of a form or
> a model instance.
The second bit is relatively mi
After several discussions with Honza, we are still on somewhat
different positions what the validator function signature should
be and how core validators should access the fields of a form or
a model instance.
In core validators, no special case handling of forms and models
is needed even in mul
On Jan 23, 4:38 pm, Marty Alchin wrote:
> I haven't been following everything, but I do have a couple comments
> to make here.
Thanks, interesting points. The get_value approach looks simpler
though, so unless you or anybody else disagrees I'll implement this.
--~--~-~--~~---
After discussing with Honza, we agreed that the dichotomy between
forms and models that was present before will remain, i.e. instance
will always be a model instance if given and all_values will always be
form.cleaned_data.
Honza's rationale was that it's common to have properties in models
and t
I haven't been following everything, but I do have a couple comments
to make here.
On Fri, Jan 23, 2009 at 8:04 AM, mrts wrote:
> works both for forms and models with the proposed approach (all_values
> is model_instance.__dict__.copy() in model field validation case).
One thing to consider is
As the uniform all values approach has created a bit of confusion, let
me present a larger example:
Validators in core.validators should not be concerned with either
model or form internals if possible. This is currently straightforward
to achieve by passing all values always as a dict via
form.c
I should be around during the weekend so I will give it a try as well...
Honza Král
E-Mail: honza.k...@gmail.com
ICQ#: 107471613
Phone: +420 606 678585
On Fri, Jan 23, 2009 at 2:56 AM, mrts wrote:
>
> On Jan 23, 3:40 am, Malcolm Tredinnick
> wrote:
>> On Thu, 2009-01-22 at 17:27 -0800, mr
On Jan 23, 3:40 am, Malcolm Tredinnick
wrote:
> On Thu, 2009-01-22 at 17:27 -0800, mrts wrote:
>
> []
>
> > A
> > side note: the `instance` attribute is not used in validator functions
> > and I can't see a clear use case for it, so it looks like it can be
> > removed -- prove me wrong pleas
On Thu, 2009-01-22 at 17:27 -0800, mrts wrote:
[]
> A
> side note: the `instance` attribute is not used in validator functions
> and I can't see a clear use case for it, so it looks like it can be
> removed -- prove me wrong please (I do see obscure corner cases where
> it could be useful --
On Jan 19, 11:23 pm, mrts wrote:
> The directory-based approach is best, I'll go with it -- but it's yet
> uncertain
> when as I have to handle pressing matters at work during daytime.
I've implemented some fundamental changes that need review. The commit
is at
http://github.com/mrts/honza-djan
On Jan 19, 1:43 pm, Malcolm Tredinnick
wrote:
> one. Short version: when the form field validation would match what the
> model field is going to do anyway, don't do anything at the form level.
> The model field validation is about to be called anyway.
[snip]
> The solution here might not be to
On Monday 19 Jan 2009 6:52:15 pm Rajeev J Sebastian wrote:
> On Mon, Jan 19, 2009 at 4:17 PM, mrts wrote:
> > And now something completely different
> > ==
> >
> > "Every problem in computer science can be solved by
> > another level of indirection."
>
> - Dav
On Mon, Jan 19, 2009 at 4:17 PM, mrts wrote:
> And now something completely different
> ==
>
> "Every problem in computer science can be solved by
> another level of indirection."
- David Wheeler
" ... except the problem of too many levels of indirection"
-
As I understand it, this is primarily about avoiding duplicate
validation of some pieces of data when it's not necessary, right? So
it's really only applicable to the ModelForm case?
This is a pretty good summary of the situation, although I suspect
there's a fairly easy solution at hand, which I
On Jan 18, 5:17 am, Malcolm Tredinnick
wrote:
> (b) Please do write it out and post it here so that we can have the
> discussion on the mailing list.
Let’s step back, distance ourselves from the current implementation
and look at how forms, models and modelforms should ideally
interact validatio
On Sat, 2009-01-17 at 09:45 -0800, mrts wrote:
> There are several problems in model validation as of now. As pouring
> them out here would create a too long, ill-formatted post, I created a
> separate page for it at
>
> http://wiki.github.com/mrts/honza-django/form-and-model-validation
(a) The
There are several problems in model validation as of now. As pouring
them out here would create a too long, ill-formatted post, I created a
separate page for it at
http://wiki.github.com/mrts/honza-django/form-and-model-validation
This is just "design gruntwork", a basic text body analyzing the
23 matches
Mail list logo
