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 <mi...@dewhirst.com.au> 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 <mi...@dewhirst.com.au > >> <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<ic_list_happy.png> > >> > >> /Connected by Motorola/ > >> > >> > >> Dean Karres <dean.kar...@gmail.com <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 <mi...@dewhirst.com.au > >> <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 todjango-users+unsubscr...@googlegroups.com > >>> <mailto:django-users+unsubscr...@googlegroups.com>. > >>> To post to this group, send email > >>> todjango-us...@googlegroups.com > >>> <mailto:django-users@googlegroups.com>. > >>> Visit this group athttps://groups.google.com/group/django-users. > >>> To view this discussion on the web > >>> visithttps:// > groups.google.com/d/msgid/django-users/22801669-96ec-4a43-a264-fd50c2544604%40googlegroups.com > >>> < > https://groups.google.com/d/msgid/django-users/22801669-96ec-4a43-a264-fd50c2544604%40googlegroups.com?utm_medium=email&utm_source=footer > >. > >>> For more options, visithttps://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 todjango-users+unsubscr...@googlegroups.com > >> <mailto:django-users+unsubscr...@googlegroups.com>. > >> To post to this group, send email todjango-us...@googlegroups.com > >> <mailto:django-users@googlegroups.com>. > >> Visit this group athttps://groups.google.com/group/django-users. > >> To view this discussion on the web > >> visithttps:// > groups.google.com/d/msgid/django-users/ajujeafh6d4qa4vvpfv2bxf9.1563085360028%40email.android.com > >> < > https://groups.google.com/d/msgid/django-users/ajujeafh6d4qa4vvpfv2bxf9.1563085360028%40email.android.com?utm_medium=email&utm_source=footer > >. > >> For more options, visithttps://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 > > <mailto:django-users+unsubscr...@googlegroups.com>. > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/django-users/A2531CD5-E89E-4EB3-84C5-CF6CEB05E53D%40hotmail.com > > < > https://groups.google.com/d/msgid/django-users/A2531CD5-E89E-4EB3-84C5-CF6CEB05E53D%40hotmail.com?utm_medium=email&utm_source=footer > >. > > -- > 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 view this discussion on the web visit > https://groups.google.com/d/msgid/django-users/485bb1ee-db33-09d3-a3d9-aebf337ade20%40dewhirst.com.au > . > -- Cheers, Matt Zand Cell: 202-420-9192 Work: 240-200-6131 High School Technology Services <https://myhsts.org/> DC Web Makers <https://dcwebmakers.com/> Coding Bootcamps <https://coding-bootcamps.com/> -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/django-users/CAJHWHyU8H5-02%2BJZ9tZkVz8nzggrjuJ%2Bca5SZVk8ZjVcT4uc%2BA%40mail.gmail.com.
