Re: Message level API awkwardness

[SmileyChris]

On Jan 11, 2:12 pm, Russell Keith-Magee 
wrote:
> I concur. get_level()/set_level() sounds like a reasonable change to
> me. Can I have that in the form of a ticket and patch? :-)

http://code.djangoproject.com/ticket/12575
-- 
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.

Re: Message level API awkwardness

[Russell Keith-Magee]

On Fri, Jan 8, 2010 at 7:10 AM, SmileyChris  wrote:
>
>
> On Jan 6, 11:09 pm, Jeremy Dunck  wrote:
>> I realize I'm very late giving feedback on the API, sorry and feel
>> free to ignore if I'm too late.
>>
>> That said, from the docs, the API to set the effective messaging level
>> is awkward:
>>
>> ==
>> # Change the messages level to ensure the debug message is added.
>> messages.get_messages(request).level = messages.DEBUG
>> ==
>>
>> To *set* the messaging level, I call .get_messages?
>>
>> I think I understand the reason this was done-- get_messages is
>> backend- and request-specific, but it is definitely surprising.
>>
>> Perhaps something like this would do better?
>>
>> messages.effective_level(request) => messages.INFO
>> messages.set_effective_level(request, messages.DEBUG)
>> ?
>>
> Yes, that sounds good. I also like Tobias' names better

I concur. get_level()/set_level() sounds like a reasonable change to
me. Can I have that in the form of a ticket and patch? :-)

Russ %-)
-- 
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.

Re: Model validation incompatibility with existing Django idioms

[Łukasz Rekucki]

2010/1/10 Tai Lee 

> On Jan 9, 12:36 am, Honza Král  wrote:
> > On Fri, Jan 8, 2010 at 11:59 AM, koenb 
> wrote:
> >
> > > On 8 jan, 10:03, James Bennett  wrote:
> >
> > >> Suppose I have a ModelForm and call save(commit=False) to get the
> > >> instance so I can do some more work on it. I'm basically saying to
> > >> Django "I don't think this object is ready to be saved yet, but I need
> > >> the object so I can do stuff to it". If Django goes ahead and does
> > >> implicit model validation there and raises an exception, it's just
> > >> telling me what I already knew: the object's not ready to be saved.
> > >> But now I get to do extra work to catch the exception, and that's bad
> > >> and wrong.
> >
> > >> Calling ModelForm.save(commit=False) should simply disable model
> > >> validation, period. If I want to validate the instance before saving
> > >> it, I'll validate the instance before saving it, but commit=False is
> > >> as clear a way as we have of saying "I'm not going to save this yet"
> > >> and model validation should respect that.
>
> I agree with this completely. Calling ModelForm.save(commit=False)
> should disable model validation, period. We're explicitly telling
> Django not to save the model because it's not ready to be saved,
> therefore no model validation needs to be performed.
>
> > > The problem is that in the idiom the is_valid() call on the modelform
> > > tries to full_validate the instance, it is not in the save
> > > (commit=False) call.
> >
> > Yes
>
> This is what I think should be changed. ModelForm.is_valid() should
> only validate the form. Model validation errors should not be (and I
> believe are not currently) returned to the user as form errors,
> because they're not form errors and the user can't do anything about
> them.


This is only true as long as we're talking about simple validators. If there
are constraints on the model that include more then one field - one which
comes from the form + a generated one - then returning it as an error may be
useful. Only validating the form is probably a good strategy, but I think
there should be an easy way of returning model validation errors to the
user.


> They're errors for the developer at the point when he or she is
> ready to save a model. Model validation should be moved out of
> ModelForm.is_valid() and into ModelForm.save(), but only if
> `commit=True`. Otherwise, model validation should be performed when
> explicitly requested.
>
> Cheers.
> Tai.
>
> --
> 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.
>
> --
Łukasz Rekucki
-- 

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.