rename internal SetPasswordForm.user into "instance" - or add it

[Christian González]

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

[Adam Johnson]

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.

--
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-develop...@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.