On Thursday, May 30, 2019 at 7:26:57 PM UTC+10, James Schneider wrote: > > I always dread being the guy that responds to his own thread with "Hey > guys, I fixed it." >
Don't beat yourself up :) No-one stops looking and just waits for the answer. You have to assume your own motivation to find it is stronger than everyone else's. It is just good manners to report back so others can stop looking. And it would be bad manners to say you fixed it without revealing the fix. Actually, no-one else even looks unless they are particularly interested or they encountered the same problem within recent memory. Except you. You have helped me more than once in the past and I appreciate it. Thank you. Ten extra points! Cheers Mike > > At any rate, I'm currently stuck having to create relatively empty >> ModelForm shell classes for the simple reason of including a form mixin >> that grabs the request before __init__() (because the ModelForm complains >> if I don't), and overrides save() to save the fields with the user object, >> in addition to specifying the form_class in the CBV along with a view mixin >> for sending the request over via get_form_kwargs(). It's quite a process, >> especially when dealing with multiple models. I could drop a significant >> amount of code if I could flag the CBV to include the request with the form >> initialization. Heck, there could even be some magic to have the form >> associate the user with specific fields on save from the view as >> form_kwargs. >> >> Or am I making things hard on myself? Thanks. >> > > For the use case above, I had an epiphany did some more experimenting and > figured out how to update the audit fields without needing to mangle a > Form/ModelForm, entirely from the CBV: > > def form_valid(self, form): > form.instance.updated_by = self.request.user > return super().form_valid(form) > > Fully compatible with an implicit ModelForm, and only 3 lines of code! > > This is an easy drop in a view mixin, which I already have for other > overrides anyway. However, this feels really gross, and I feel like I'm > violating some prime directive by attaching data to an instance that was > not validated by the form. I think I can forgive myself since the data I'm > attaching is coming from Django and not some other source, and I have to > assume Django handles these things properly. > > Of course while writing this message, I then stumbled on this exact > solution buried in the Django docs: > > > https://docs.djangoproject.com/en/dev/topics/class-based-views/generic-editing/#models-and-request-user > > So, feel free to ignore me. I will grant myself a point for coming up with > the same solution already blessed by the Django devs. I'm also deducting a > point from myself for not RTFM properly, so I break even. > > -James > -- 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/45a778f0-9977-4320-a791-912c4d66f826%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.