Re: New user question: Where to put non-form validation code?

[Matt Zand]

Hi everyone,
Does anyone know how to post blog at below page:
https://www.djangoproject.com/community/blogs/

I am really frustrated as I submitted last week but nothing is there. Who
is in charge of blog posts on Django site?

Thx,
Matt



On Thu, Jul 25, 2019 at 12:38 AM Mike Dewhirst 
wrote:

> On 25/07/2019 1:03 pm, Jim Illback wrote:
> > I had a slight variation on this thread - where to put some M2M field
> > validation/deletion logic.
> >
> > I have a purely model-based form where a checkbox’s value determines
> > whether another field (it’s a M2M field) in the form should be NULL or
> > keep its values to be saved in the database. So, following the
> > appropriate separation of concerns as advocated below, I added logic
> > in both the models' clean and save override methods. Neither approach
> > set the other field to NULL when it should have been. The reason is
> > the form still contained M2M values even though the model said to
> > delete them (delete the set, actually).
> >
> > After a lot of trial and error, it turns out that the model’s save
> > seems to be run BEFORE the form’s save. To me, that seems backwards.
> > Shouldn’t the model’s processes (which are directly relate to the
> > database, the ultimate data source) occur last and well before the
> > form’s (which are merely an interaction with the user)? What was
> > happening was my model’s delete actually did the deletions (those IDs
> > were gone), but then the form’s processing came along afterwards and
> > re-inserted them again (with brand new IDs).
>
> Don't know what's happening here but you can be sure Django is doing it
> the right way.
>
> Maybe you need to look at your on_delete constants. models.CASCADE
> versus models.SET_NULL or models.PROTECT
>
> >
> > Can someone help me understand why Django has chosen this seemingly
> > “inversion” of processing - first models’ processes, then forms’? And,
> > perhaps more importantly, where should this either/or logic should be
> > placed so it will take effect?
> >
> > Thanks very much,
> > Jim Illback
> >
> >> On Jul 13, 2019, at 11:48 PM, Mike Dewhirst  >> > wrote:
> >>
> >> Well yes it could be called multifaceted.
> >>
> >> Usually but not always the interface with the user is the form. You
> >> can have non-database fields as well as model fields so either way
> >> there has to be a full suite of validation functionality available in
> >> both types of forms. Luckily, model forms automatically call
> >> model.clean() for you.
> >>
> >> Unit tests don't though. You have deliberately call obj.clean() if
> >> you want to test things. obj.save() doesn't call obj.clean().
> >>
> >> Actually, I also do a bit in view code too especially if there are
> >> non-database or hidden fields in the form. I know you are not
> >> supposed to validate data in a view for proper separation of concerns
> >> but it does keep my forms neater.
> >>
> >> The bottom line for me is that if I can imagine non-form access ...
> >> eg through an API ... then all validation possible has to be via
> >> model.clean() and the API has to remember to call clean() before
> >> saving every time there is a POST
> >>
> >> Hence I*always*put business rules validation in model.clean() and
> >> leave 'local' validation for the form.
> >>
> >> You are right. There are quite a few moving parts
> >>
> >> /Connected by Motorola/
> >>
> >>
> >> Dean Karres mailto:dean.kar...@gmail.com>>
> wrote:
> >>
> >> Thank you. There are way more parts to this than I would have imagined.
> >>
> >>
> >>
> >> On Sat, Jul 13, 2019, 8:01 PM Mike Dewhirst  >> > wrote:
> >>
> >> On 14/07/2019 10:37 am, Dean Karres wrote:
> >>> Hi,
> >>>
> >>> I am learning Django.  I am using CBVs.  My default "index.py"
> >>> view is basically a dashboard for the app I am playing with.  As
> >>> my models and views become more complicated I want to be able to
> >>> ask, for any model instance, is this instance "valid" or
> >>> "complete".  Valid means that all Required elements are present
> >>> and have reasonable values.  "Complete" means that an instance
> >>> is "valid" but also some specific bits of additional info are
> >>> also ok.
> >>>
> >>> For example I have a Student model that has name and address
> >>> info.  There is a ManyToMany relation to the Class(es) in which
> >>> that Student is enrolled.  A "student" instance is valid if the
> >>> name and address fields are filled.  A student is "complete" if
> >>> the student is valid and has signed up for one or more classes.
> >>>
> >>> So, my question is: where should the valid and complete methods
> >>> live?  Should they be in the Student model or CBV? Someplace
> >>> else?  Does it matter?
> >>
> >> I like to put that sort of stuff into model methods then add
> >> model.clean() to call them and raise whatever error may be
> >> appropriate if they fail.

Re: New user question: Where to put non-form validation code?

[Mike Dewhirst]

On 25/07/2019 1:03 pm, Jim Illback wrote:
I had a slight variation on this thread - where to put some M2M field 
validation/deletion logic.


I have a purely model-based form where a checkbox’s value determines 
whether another field (it’s a M2M field) in the form should be NULL or 
keep its values to be saved in the database. So, following the 
appropriate separation of concerns as advocated below, I added logic 
in both the models' clean and save override methods. Neither approach 
set the other field to NULL when it should have been. The reason is 
the form still contained M2M values even though the model said to 
delete them (delete the set, actually).


After a lot of trial and error, it turns out that the model’s save 
seems to be run BEFORE the form’s save. To me, that seems backwards. 
Shouldn’t the model’s processes (which are directly relate to the 
database, the ultimate data source) occur last and well before the 
form’s (which are merely an interaction with the user)? What was 
happening was my model’s delete actually did the deletions (those IDs 
were gone), but then the form’s processing came along afterwards and 
re-inserted them again (with brand new IDs).


Don't know what's happening here but you can be sure Django is doing it 
the right way.


Maybe you need to look at your on_delete constants. models.CASCADE 
versus models.SET_NULL or models.PROTECT




Can someone help me understand why Django has chosen this seemingly 
“inversion” of processing - first models’ processes, then forms’? And, 
perhaps more importantly, where should this either/or logic should be 
placed so it will take effect?


Thanks very much,
Jim Illback

On Jul 13, 2019, at 11:48 PM, Mike Dewhirst > wrote:


Well yes it could be called multifaceted.

Usually but not always the interface with the user is the form. You 
can have non-database fields as well as model fields so either way 
there has to be a full suite of validation functionality available in 
both types of forms. Luckily, model forms automatically call 
model.clean() for you.


Unit tests don't though. You have deliberately call obj.clean() if 
you want to test things. obj.save() doesn't call obj.clean().


Actually, I also do a bit in view code too especially if there are 
non-database or hidden fields in the form. I know you are not 
supposed to validate data in a view for proper separation of concerns 
but it does keep my forms neater.


The bottom line for me is that if I can imagine non-form access ... 
eg through an API ... then all validation possible has to be via 
model.clean() and the API has to remember to call clean() before 
saving every time there is a POST


Hence I*always*put business rules validation in model.clean() and 
leave 'local' validation for the form.


You are right. There are quite a few moving parts

/Connected by Motorola/


Dean Karres mailto:dean.kar...@gmail.com>> wrote:

Thank you. There are way more parts to this than I would have imagined.



On Sat, Jul 13, 2019, 8:01 PM Mike Dewhirst > wrote:


On 14/07/2019 10:37 am, Dean Karres wrote:

Hi,

I am learning Django.  I am using CBVs.  My default "index.py"
view is basically a dashboard for the app I am playing with.  As
my models and views become more complicated I want to be able to
ask, for any model instance, is this instance "valid" or
"complete".  Valid means that all Required elements are present
and have reasonable values.  "Complete" means that an instance
is "valid" but also some specific bits of additional info are
also ok.

For example I have a Student model that has name and address
info.  There is a ManyToMany relation to the Class(es) in which
that Student is enrolled.  A "student" instance is valid if the
name and address fields are filled.  A student is "complete" if
the student is valid and has signed up for one or more classes.

So, my question is: where should the valid and complete methods
live?  Should they be in the Student model or CBV? Someplace
else?  Does it matter?


I like to put that sort of stuff into model methods then add
model.clean() to call them and raise whatever error may be
appropriate if they fail.


https://docs.djangoproject.com/en/2.1/topics/forms/modelforms/#interaction-with-model-validation

and


https://docs.djangoproject.com/en/2.1/ref/models/instances/#validating-objects

and


https://docs.djangoproject.com/en/2.1/ref/models/instances/#django.db.models.Model.clean

You can raise your own errors which inherit from ValidationError
to fine tune the process. For example, I differentiate between
BusinessRuleViolation and InvalidToken and a couple of others
where that delivers better control.




Cheers
--
You received this message because you are subscribed to the
Google Groups "Django users" group.
To unsubscribe from this grou

Re: New user question: Where to put non-form validation code?

[Mike Dewhirst]

On 25/07/2019 1:03 pm, Jim Illback wrote:
I had a slight variation on this thread - where to put some M2M field 
validation/deletion logic.


I have a purely model-based form where a checkbox’s value determines 
whether another field (it’s a M2M field) in the form should be NULL or 
keep its values to be saved in the database. So, following the 
appropriate separation of concerns as advocated below, I added logic 
in both the models' clean and save override methods. Neither approach 
set the other field to NULL when it should have been. The reason is 
the form still contained M2M values even though the model said to 
delete them (delete the set, actually).


There's a bit of trapeze happening here. The form is always in mid-air. 
No matter what happens in the form the model save is only called when 
all the validation (ie form first for the obvious errors then model for 
business rules) has succeeded.


So, boolean (or any other) field values don't make it into the database 
until model.save() succeeds.


And, the framework logic has to cope with database rejection of the 
values as well. So the entire transaction needs to be able to roll back 
if something goes awry at the last moment. Keep your eye on 
transactions. I think PostgreSQL is probably the best of the open source 
RDBMSs for that. I know Django seems to have no problems with it.


My typical approach in the model to see things before and after the save 
is ...


def save(self, *args, **kwargs:
    var_to_be_passed = self._pre_save()
    super(ThisModel, self).save(*args, **kwargs)
    self._post_save(var_to_be_passed)

I use self._post_save() usually to do additional database things like 
creating child models.


If your user-initiated change relies on a value in the database then you 
have to save it first so it gets there.


Also, remember that the model's clean() method is only ever called by 
Django when a ModelForm is used. Otherwise you have to call it yourself. 
That's where I put all my business rule validation. I typically have 
separate mofel methods and just call thin in clean() and raise 
validation errors if necessary. That is totally appropriate because a 
Django form knows how to deal with them.


As I said previously, in unti tests you have to call clean() explicitly.



After a lot of trial and error, it turns out that the model’s save 
seems to be run BEFORE the form’s save. To me, that seems backwards. 
Shouldn’t the model’s processes (which are directly relate to the 
database, the ultimate data source) occur last and well before the 
form’s (which are merely an interaction with the user)? What was 
happening was my model’s delete actually did the deletions (those IDs 
were gone), but then the form’s processing came along afterwards and 
re-inserted them again (with brand new IDs).


Can someone help me understand why Django has chosen this seemingly 
“inversion” of processing - first models’ processes, then forms’? And, 
perhaps more importantly, where should this either/or logic should be 
placed so it will take effect?


Thanks very much,
Jim Illback

On Jul 13, 2019, at 11:48 PM, Mike Dewhirst > wrote:


Well yes it could be called multifaceted.

Usually but not always the interface with the user is the form. You 
can have non-database fields as well as model fields so either way 
there has to be a full suite of validation functionality available in 
both types of forms. Luckily, model forms automatically call 
model.clean() for you.


Unit tests don't though. You have deliberately call obj.clean() if 
you want to test things. obj.save() doesn't call obj.clean().


Actually, I also do a bit in view code too especially if there are 
non-database or hidden fields in the form. I know you are not 
supposed to validate data in a view for proper separation of concerns 
but it does keep my forms neater.


The bottom line for me is that if I can imagine non-form access ... 
eg through an API ... then all validation possible has to be via 
model.clean() and the API has to remember to call clean() before 
saving every time there is a POST


Hence I*always*put business rules validation in model.clean() and 
leave 'local' validation for the form.


You are right. There are quite a few moving parts

/Connected by Motorola/


Dean Karres mailto:dean.kar...@gmail.com>> wrote:

Thank you. There are way more parts to this than I would have imagined.



On Sat, Jul 13, 2019, 8:01 PM Mike Dewhirst > wrote:


On 14/07/2019 10:37 am, Dean Karres wrote:

Hi,

I am learning Django.  I am using CBVs.  My default "index.py"
view is basically a dashboard for the app I am playing with.  As
my models and views become more complicated I want to be able to
ask, for any model instance, is this instance "valid" or
"complete".  Valid means that all Required elements are present
and have reasonable values.  "Complete" means that an instance
is "valid" but al

Re: New user question: Where to put non-form validation code?

[Jim Illback]

I had a slight variation on this thread - where to put some M2M field 
validation/deletion logic.

I have a purely model-based form where a checkbox’s value determines whether 
another field (it’s a M2M field) in the form should be NULL or keep its values 
to be saved in the database. So, following the appropriate separation of 
concerns as advocated below, I added logic in both the models' clean and save 
override methods. Neither approach set the other field to NULL when it should 
have been. The reason is the form still contained M2M values even though the 
model said to delete them (delete the set, actually).

After a lot of trial and error, it turns out that the model’s save seems to be 
run BEFORE the form’s save. To me, that seems backwards. Shouldn’t the model’s 
processes (which are directly relate to the database, the ultimate data source) 
occur last and well before the form’s (which are merely an interaction with the 
user)? What was happening was my model’s delete actually did the deletions 
(those IDs were gone), but then the form’s processing came along afterwards and 
re-inserted them again (with brand new IDs).

Can someone help me understand why Django has chosen this seemingly “inversion” 
of processing - first models’ processes, then forms’? And, perhaps more 
importantly, where should this either/or logic should be placed so it will take 
effect?

Thanks very much,
Jim Illback

On Jul 13, 2019, at 11:48 PM, Mike Dewhirst 
mailto:mi...@dewhirst.com.au>> wrote:

Well yes it could be called multifaceted.

Usually but not always the interface with the user is the form. You can have 
non-database fields as well as model fields so either way there has to be a 
full suite of validation functionality available in both types of forms. 
Luckily, model forms automatically call model.clean() for you.

Unit tests don't though. You have deliberately call obj.clean() if you want to 
test things. obj.save() doesn't call obj.clean().

Actually, I also do a bit in view code too especially if there are non-database 
or hidden fields in the form. I know you are not supposed to validate data in a 
view for proper separation of concerns but it does keep my forms neater.

The bottom line for me is that if I can imagine non-form access ... eg through 
an API ... then all validation possible has to be via model.clean() and the API 
has to remember to call clean() before saving every time there is a POST

Hence I always put business rules validation in model.clean() and leave 'local' 
validation for the form.

You are right. There are quite a few moving parts 

Connected by Motorola


Dean Karres mailto:dean.kar...@gmail.com>> wrote:

Thank you. There are way more parts to this than I would have imagined.



On Sat, Jul 13, 2019, 8:01 PM Mike Dewhirst 
mailto:mi...@dewhirst.com.au>> wrote:
On 14/07/2019 10:37 am, Dean Karres wrote:
Hi,

I am learning Django.  I am using CBVs.  My default "index.py" view is 
basically a dashboard for the app I am playing with.  As my models and views 
become more complicated I want to be able to ask, for any model instance, is 
this instance "valid" or "complete".  Valid means that all Required elements 
are present and have reasonable values.  "Complete" means that an instance is 
"valid" but also some specific bits of additional info are also ok.

For example I have a Student model that has name and address info.  There is a 
ManyToMany relation to the Class(es) in which that Student is enrolled.  A 
"student" instance is valid if the name and address fields are filled.  A 
student is "complete" if the student is valid and has signed up for one or more 
classes.

So, my question is: where should the valid and complete methods live?  Should 
they be in the Student model or CBV?  Someplace else?  Does it matter?

I like to put that sort of stuff into model methods then add model.clean() to 
call them and raise whatever error may be appropriate if they fail.

https://docs.djangoproject.com/en/2.1/topics/forms/modelforms/#interaction-with-model-validation

and

https://docs.djangoproject.com/en/2.1/ref/models/instances/#validating-objects

and

https://docs.djangoproject.com/en/2.1/ref/models/instances/#django.db.models.Model.clean

You can raise your own errors which inherit from ValidationError to fine tune 
the process. For example, I differentiate between BusinessRuleViolation and 
InvalidToken and a couple of others where that delivers better control.



Cheers
--
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 
django-users+unsubscr...@googlegroups.com.
To post to this group, send email to 
django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msg

Re: New user question: Where to put non-form validation code?

[Mike Dewhirst]

Well yes it could be called multifaceted.  

Usually but not always the interface with the user is the form. You can have 
non-database fields as well as model fields so either way there has to be a 
full suite of validation functionality available in both types of forms. 
Luckily, model forms automatically call model.clean() for you. 

Unit tests don't though. You have deliberately call obj.clean() if you want to 
test things. obj.save() doesn't call obj.clean().

Actually, I also do a bit in view code too especially if there are non-database 
or hidden fields in the form. I know you are not supposed to validate data in a 
view for proper separation of concerns but it does keep my forms neater.

The bottom line for me is that if I can imagine non-form access ... eg through 
an API ... then all validation possible has to be via model.clean() and the API 
has to remember to call clean() before saving every time there is a POST

Hence I always put business rules validation in model.clean() and leave 'local' 
validation for the form. 

You are right. There are quite a few moving parts  :-) 

Connected by Motorola

Dean Karres  wrote:

>Thank you. There are way more parts to this than I would have imagined.
>
>
>
>
>On Sat, Jul 13, 2019, 8:01 PM Mike Dewhirst  wrote:
>
>On 14/07/2019 10:37 am, Dean Karres wrote:
>
>Hi, 
>
>
>I am learning Django.  I am using CBVs.  My default "index.py" view is 
>basically a dashboard for the app I am playing with.  As my models and views 
>become more complicated I want to be able to ask, for any model instance, is 
>this instance "valid" or "complete".  Valid means that all Required elements 
>are present and have reasonable values.  "Complete" means that an instance is 
>"valid" but also some specific bits of additional info are also ok.
>
>
>For example I have a Student model that has name and address info.  There is a 
>ManyToMany relation to the Class(es) in which that Student is enrolled.  A 
>"student" instance is valid if the name and address fields are filled.  A 
>student is "complete" if the student is valid and has signed up for one or 
>more classes.
>
>
>So, my question is: where should the valid and complete methods live?  Should 
>they be in the Student model or CBV?  Someplace else?  Does it matter?
>
>
>I like to put that sort of stuff into model methods then add model.clean() to 
>call them and raise whatever error may be appropriate if they fail.
>
>https://docs.djangoproject.com/en/2.1/topics/forms/modelforms/#interaction-with-model-validation
>
>and
>
>https://docs.djangoproject.com/en/2.1/ref/models/instances/#validating-objects
>
>and
>
>https://docs.djangoproject.com/en/2.1/ref/models/instances/#django.db.models.Model.clean
>
>You can raise your own errors which inherit from ValidationError to fine tune 
>the process. For example, I differentiate between BusinessRuleViolation and 
>InvalidToken and a couple of others where that delivers better control.
>
>
>
>Cheers
>
>-- 
>You received this message because you are subscribed to the Google Groups 
>"Django users" group.
>To unsubscribe from this group and stop receiving emails from it, send an 
>email to django-users+unsubscr...@googlegroups.com.
>To post to this group, send email to django-users@googlegroups.com.
>Visit this group at https://groups.google.com/group/django-users.
>To view this discussion on the web visit 
>https://groups.google.com/d/msgid/django-users/22801669-96ec-4a43-a264-fd50c2544604%40googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/ajujeafh6d4qa4vvpfv2bxf9.1563085360028%40email.android.com.
For more options, visit https://groups.google.com/d/optout.

RE: New user question: Where to put non-form validation code?

[laya]

Hi
If I got your meaning Truly. It should be mentioned that as I know there is not 
any difference for using validation in model or View . Usually in model, we use 
regex for validation and in View  it needs to use some methods for Email 
Validation and etc.

Sent from Mail for Windows 10

From: Dean Karres
Sent: Saturday, July 13, 2019 5:40 PM
To: Django users
Subject: New user question: Where to put non-form validation code?

Hi,

I am learning Django.  I am using CBVs.  My default "index.py" view is 
basically a dashboard for the app I am playing with.  As my models and views 
become more complicated I want to be able to ask, for any model instance, is 
this instance "valid" or "complete".  Valid means that all Required elements 
are present and have reasonable values.  "Complete" means that an instance is 
"valid" but also some specific bits of additional info are also ok.

For example I have a Student model that has name and address info.  There is a 
ManyToMany relation to the Class(es) in which that Student is enrolled.  A 
"student" instance is valid if the name and address fields are filled.  A 
student is "complete" if the student is valid and has signed up for one or more 
classes.

So, my question is: where should the valid and complete methods live?  Should 
they be in the Student model or CBV?  Someplace else?  Does it matter?

Cheers
-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/22801669-96ec-4a43-a264-fd50c2544604%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/5d2ab038.1c69fb81.ede47.7dde%40mx.google.com.
For more options, visit https://groups.google.com/d/optout.

Re: New user question: Where to put non-form validation code?

[Dean Karres]

Thank you. There are way more parts to this than I would have imagined.



On Sat, Jul 13, 2019, 8:01 PM Mike Dewhirst  wrote:

> On 14/07/2019 10:37 am, Dean Karres wrote:
>
> Hi,
>
> I am learning Django.  I am using CBVs.  My default "index.py" view is
> basically a dashboard for the app I am playing with.  As my models and
> views become more complicated I want to be able to ask, for any model
> instance, is this instance "valid" or "complete".  Valid means that all
> Required elements are present and have reasonable values.  "Complete" means
> that an instance is "valid" but also some specific bits of additional info
> are also ok.
>
> For example I have a Student model that has name and address info.  There
> is a ManyToMany relation to the Class(es) in which that Student is
> enrolled.  A "student" instance is valid if the name and address fields are
> filled.  A student is "complete" if the student is valid and has signed up
> for one or more classes.
>
> So, my question is: where should the valid and complete methods live?
> Should they be in the Student model or CBV?  Someplace else?  Does it
> matter?
>
>
> I like to put that sort of stuff into model methods then add model.clean()
> to call them and raise whatever error may be appropriate if they fail.
>
>
> https://docs.djangoproject.com/en/2.1/topics/forms/modelforms/#interaction-with-model-validation
>
> and
>
>
> https://docs.djangoproject.com/en/2.1/ref/models/instances/#validating-objects
>
> and
>
>
> https://docs.djangoproject.com/en/2.1/ref/models/instances/#django.db.models.Model.clean
>
> You can raise your own errors which inherit from ValidationError to fine
> tune the process. For example, I differentiate between
> BusinessRuleViolation and InvalidToken and a couple of others where that
> delivers better control.
>
>
>
> Cheers
> --
> You received this message because you are subscribed to the Google Groups
> "Django users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-users+unsubscr...@googlegroups.com.
> To post to this group, send email to django-users@googlegroups.com.
> Visit this group at https://groups.google.com/group/django-users.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-users/22801669-96ec-4a43-a264-fd50c2544604%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAO%2B1Q_uv_PN%3Dm8Ny5zWyQVGbSkY2mnwZJO-dYQy2yL8CbOTgsw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: New user question: Where to put non-form validation code?

[Mike Dewhirst]

On 14/07/2019 10:37 am, Dean Karres wrote:

Hi,

I am learning Django.  I am using CBVs.  My default "index.py" view is 
basically a dashboard for the app I am playing with.  As my models and 
views become more complicated I want to be able to ask, for any model 
instance, is this instance "valid" or "complete".  Valid means that 
all Required elements are present and have reasonable values.  
"Complete" means that an instance is "valid" but also some specific 
bits of additional info are also ok.


For example I have a Student model that has name and address info.  
There is a ManyToMany relation to the Class(es) in which that Student 
is enrolled.  A "student" instance is valid if the name and address 
fields are filled.  A student is "complete" if the student is valid 
and has signed up for one or more classes.


So, my question is: where should the valid and complete methods live?  
Should they be in the Student model or CBV? Someplace else?  Does it 
matter?


I like to put that sort of stuff into model methods then add 
model.clean() to call them and raise whatever error may be appropriate 
if they fail.


https://docs.djangoproject.com/en/2.1/topics/forms/modelforms/#interaction-with-model-validation

and

https://docs.djangoproject.com/en/2.1/ref/models/instances/#validating-objects

and

https://docs.djangoproject.com/en/2.1/ref/models/instances/#django.db.models.Model.clean

You can raise your own errors which inherit from ValidationError to fine 
tune the process. For example, I differentiate between 
BusinessRuleViolation and InvalidToken and a couple of others where that 
delivers better control.





Cheers
--
You received this message because you are subscribed to the Google 
Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send 
an email to django-users+unsubscr...@googlegroups.com 
.
To post to this group, send email to django-users@googlegroups.com 
.

Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/22801669-96ec-4a43-a264-fd50c2544604%40googlegroups.com 
.

For more options, visit https://groups.google.com/d/optout.


--
You received this message because you are subscribed to the Google Groups "Django 
users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/d97da99d-4d15-1467-251b-487e604f0b18%40dewhirst.com.au.
For more options, visit https://groups.google.com/d/optout.

New user question: Where to put non-form validation code?

[Dean Karres]

Hi,

I am learning Django.  I am using CBVs.  My default "index.py" view is 
basically a dashboard for the app I am playing with.  As my models and 
views become more complicated I want to be able to ask, for any model 
instance, is this instance "valid" or "complete".  Valid means that all 
Required elements are present and have reasonable values.  "Complete" means 
that an instance is "valid" but also some specific bits of additional info 
are also ok.

For example I have a Student model that has name and address info.  There 
is a ManyToMany relation to the Class(es) in which that Student is 
enrolled.  A "student" instance is valid if the name and address fields are 
filled.  A student is "complete" if the student is valid and has signed up 
for one or more classes.

So, my question is: where should the valid and complete methods live?  
Should they be in the Student model or CBV?  Someplace else?  Does it 
matter?

Cheers

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/22801669-96ec-4a43-a264-fd50c2544604%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.