Catching Exceptions thrown in .save() - django 1.0

[Kurczak]

Hello there,
I'm in need of some kind of validation at model level (and don't have
time to wait till 1.1 lands). Now I'm doing it by raising exceptions
in save method (I know how ugly it sounds).
What can I do to propagate those exceptions to forms or handle them at
some user-friendly level (so at least i can show some nice error
page).
thanks

[Michael Newman]

Kurczak;

Short of this is, catching specific errors in the save method and
displaying them to the user are hard and you might be regurgitating
items back to the user that they really don't have any business seeing
(SQL errors, programming errors, etc.). The best way to check for the
proper values is to do it at the form level. If you are in the admin
you have the ability to define a custom form; the admin docs explain
this pretty well: http://docs.djangoproject.com/en/dev/ref/contrib/admin/#form
. If this is a custom input of your form, you save one step and do it
in the clean methods on your form.

In this way you are avoiding the model validation on the save method
and you have clean modular and specific errors that can be displayed
to the user.

Hope that helps,

Michael

[Kurczak]

Thank you for your input.
I'd rather use forms and clean_<name> method, but I need to get
object's pk (it object exists in db),
is there any proper way to get it?
I know I can override form's __init__ and pass the model, but I can't
figure out which method creates the form and if I can pass model from
there.
Thanks,
Kurczak

[Michael]

Thank you for your input.
I'd rather use forms and clean_<name> method, but I need to get
object's pk (it object exists in db),
is there any proper way to get it?
I know I can override form's __init__ and pass the model, but I can't
figure out which method creates the form and if I can pass model from
there.
Thanks,
Kurczak

You can actually get to the instance of an object from the modelform's clean methods through self.instance without hacking init. So with that you can check for self.instance.pk and see what it is. I hope that helps, Mn

[Kurczak]

Amazing!
Thank you so much.
Kurczak

[bruno desthuilliers]

On 2 oct, 16:51, Michael Newman <newmani...@gmail.com> wrote:
> Kurczak;
>
> Short of this is, catching specific errors in the save method and
> displaying them to the user are hard and you might be regurgitating
> items back to the user that they really don't have any business seeing
> (SQL errors, programming errors, etc.).

So far so good.

> The best way to check for the
> proper values is to do it at the form level.

(snip)

> In this way you are avoiding the model validation on the save method

Err...

The best way is to do it at *both* levels (yes, not totally DRY,
but...). The model is responsible for data correctness and integrity.
You definitively don't want to "avoid model validation" and allow a
model object with incorrect data to be saved.

My 2 cents.

[Michael]

Sigh. Model level validation is going to get into Django at some point. However, doing this type of checking is not model level validation, and no matter where it is put, will not become model level validation. Here you are validating input, checking and cleaning it and reporting back to the user. The best way to do that is in the form's clean methods. 

[bruno desthuilliers]

On 3 oct, 01:34, Michael <newmani...@gmail.com> wrote:
> On Thu, Oct 2, 2008 at 6:23 PM, bruno desthuilliers <
>
>
>
> bruno.desthuilli...@gmail.com> wrote:
>
> > On 2 oct, 16:51, Michael Newman <newmani...@gmail.com> wrote:
> > > Kurczak;
>
> > > Short of this is, catching specific errors in the save method and
> > > displaying them to the user are hard and you might be regurgitating
> > > items back to the user that they really don't have any business seeing
> > > (SQL errors, programming errors, etc.).
>
> > So far so good.
>
> > > The best way to check for the
> > > proper values is to do it at the form level.
>
> > (snip)
>
> > > In this way you are avoiding the model validation on the save method
>
> > Err...
>
> > The best way is to do it at *both* levels (yes, not totally DRY,
> > but...). The model is responsible for data correctness and integrity.
> > You definitively don't want to "avoid model validation" and allow a
> > model object with incorrect data to be saved.
>
> > My 2 cents.
>
> Sigh. Model level validation is going to get into Django at some point.

There even was a short-lived first attempt at it.

> However, doing this type of checking is not model level validation,

Which "type of checking" ? You wrote "The best way to check for the
proper values is to do it at the form level.". Are you pretending that
"proper values" are not the business of the models ???

> and no
> matter where it is put, will not become model level validation. Here you are
> validating input, checking and cleaning it
> and reporting back to the user.
> The best way to do that is in the form's clean methods.

Not all validation can be done by the controller, and models are not
necessarily accessed thru one single controller. Heck, there's just no
point having models at all if the controllers have to micro-manage
them. So while the controller indeed has to hand the model sensible
data (which usually requires some conversion, which themselves are a
first validation stage) and
to provide usefull feedback to the user (which usually imply handling
a first validation stage), this doesn't mean the models should just
take whatever the controller fed him and be happy with it. I can
assure you - and believe me, I learned that lesson the hard way - that
bypassing model-level validation "because the controller already did
it" is *not* an option. period. At least in my team (I have better
things to do than trying to recover from corrupted data in a
customer's mission-critical app, thanks). Now if you're willing to
take the risk, well, it's your life, but at least pity other
developpers and do not advise doing so.

[bruno desthuilliers]

On 3 oct, 15:44, bruno desthuilliers <bruno.desthuilli...@gmail.com>
wrote:
(snip)

Re-reading this (wrote it a bit in hurry) I'm afraid the tone is a bit
harsh and controversial. Michael, please accept my apologies, I didn't
mean to flame you - just explain why I disagree with you on this
point.