I don’t think it’s worth adding support for “instance”. The name “instance”
is used in generic mode view classes because they work with any kind of
object. Since the password change view knows it has a user, it can use the
more specific variable name.
You can add an “instance” property in your own subclass if that helps.
On Thu, 24 Nov 2022 at 10:59, Christian González <
christian.gonza...@nerdocs.at> wrote:
> Hi Django people,
>
> I'm having trouble using the built-in
> django.contrib.auth.forms.PasswordChangeForm (which is a SetPasswordForm
> child), called from PasswordChangeView.
>
> I know it is just a kind of example, as there is no actual documentation
> of the class, but should be usable stable too in projects, unmodified.
> It is mentioned in
>
> https://docs.djangoproject.com/en/4.1/topics/auth/default/#django.contrib.auth.forms.SetPasswordForm
> - but never explained, other than "A form that lets a user change their
> password without entering the old password." There is no official API.
>
> I use the view as base class for my own HTMX view, and with some other
> mixins (that auto-generate some user data) for all the sub views.
>
> For all the other forms in this group (which are ModelViews), "instance"
> is the parameter where the form binds it's internal model to.
> PasswordChangeForm is a Form (no ModelForm), as it does not make use of
> all the ModelForm automagic behaviour and creates 2 password fields
> itself. This is all fine. But in a row of forms each accepting
> "instance" as data source, this Form steps aside and uses "user" as
> argument.
>
> I can see a practicability in it, as it seems to be straightforward if
> you use this view alone - but it does not comply to other Django Forms,
> and has to be treated as "special" using get_form_kwargs() -> {"user":
> ...} in views using it.
>
>
> So my idea is (which may be bad - I could just copy that whole form+view
> and reproduce it with "instance" instead of "user", but DRY, ya know) :
> What would you say to renaming this "user" parameter into "instance" -
> it would make the view compatible to others, especially ModelForms.
>
> Drawbacks: It would break compatibility with every usage that directly
> calls the form with the "user" parameter. PasswordChangeView could be
> changed, so everyone using *that* would be save. only direct usage would
> be affected.
>
> But, would it be a possibility to stay compatible and add a second
> (optional) parameter named "instance"? The form could then just decide
> in __init__ if (user|instance) is present, and save the one that is
> present as self.user.
>
> This would ensure that the view could also call it with "instance", both
> would work.
>
> Anything speaking against that?
>
> Best regards,
>
> Christian
>
> --
> Dr. Christian González
> https://nerdocs.at
>
> --
> You received this message because you are subscribed to the Google Groups
> "Django developers (Contributions to Django itself)" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to django-developers+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/django-developers/a9b28310-88fc-912b-fe56-91589f50b7e1%40nerdocs.at
> .
>
--
You received this message because you are subscribed to the Google Groups
"Django developers (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-developers/CAMyDDM0c_1uWuKMe4Za7wArDWm0KjwvbxtWuAwvF0q7fzS6egw%40mail.gmail.com.
