Opened 4 years ago

Closed 3 years ago

Last modified 3 years ago

#18872 closed New feature (fixed)

Add prefix attribute to FormMixin

Reported by: dragonsnaker@… Owned by: anonymous
Component: Generic views Version: master
Severity: Normal Keywords: FormMixin prefix
Cc: ibustamante Triage Stage: Accepted
Has patch: yes Needs documentation: yes
Needs tests: yes Patch needs improvement: yes
Easy pickings: yes UI/UX: no


I just want to suggest adding a "prefix" attribute, and its corresponding get_prefix() method, to the django.views.generix.edit.FormMixin, in order to make it possible to add a prefix to the form.

I'll attach a patch later, in case my suggestion is considered.

Change History (19)

comment:1 Changed 4 years ago by ibustamante

Cc: ibustamante added
Needs documentation: unset
Needs tests: unset
Patch needs improvement: unset

comment:2 Changed 4 years ago by ibustamante

Owner: changed from nobody to ibustamante
Status: newassigned

comment:3 Changed 4 years ago by ibustamante

Has patch: set

comment:4 Changed 4 years ago by ibustamante

Version: 1.4master

comment:5 Changed 4 years ago by ibustamante

Summary: Adding prefix attribute to FormMixinAdd prefix attribute to FormMixin

comment:6 Changed 4 years ago by Łukasz Rekucki

Needs tests: set
Patch needs improvement: set
Triage Stage: UnreviewedAccepted

Please submit patches as either diff attachments or links to *pull request*, which makes them easy to review.

comment:7 in reply to:  6 Changed 4 years ago by ibustamante

Created a pull request to add the patch as requested:

comment:8 Changed 4 years ago by Zbigniew Siciarz

Owner: changed from ibustamante to Zbigniew Siciarz

comment:9 Changed 4 years ago by Zbigniew Siciarz

Needs documentation: set

comment:10 Changed 4 years ago by Zbigniew Siciarz

Well, just a thought: prefixes are used to discriminate between multiple forms within the same view. Since the FormMixin handles only one form, what's the use case for setting a custom prefix for that form?

comment:11 Changed 4 years ago by konradhalas

Yes, but you can always create two (and more) different forms within one page and with prefix field you can avoid inputs name collision.

comment:12 Changed 4 years ago by ibustamante

I want to reinforce what @konradhalas said. It's possible to have multiple forms on the same page when you're using AJAX, for example. In this case you would need to have a prefix set, so as to avoid input id collision.

comment:13 Changed 4 years ago by druidjaidan

Have to agree. There are lots of reasons you might need to use a prefix that don't involve processing more than one form. I ran into this because we had a form on the page that acted as a context switcher, changing it's value caused the form to be processed, changed a session value, and reloaded the page given the new context. This caused an id collision anytime the user was on a page that happened to have a form that had the same field name (really common considering the context was a FK).

comment:14 Changed 3 years ago by Daniele Procida

Owner: changed from Zbigniew Siciarz to Daniele Procida

I have tentatively reserved this ticket for first-time committers who take part in the Don't be afraid to commit workshop at the DjangoCon Europe 2013 sprints on 18th and 19th May.

If you want to tackle this ticket before then, please don't let the fact that it's assigned to me stop you. Feel free to re-assign it to yourself and do whatever you like to it.

Note - the pull request for this one has been closed because "it needs docs and tests". You know what to do...

comment:15 Changed 3 years ago by alasdair

Owner: changed from Daniele Procida to anonymous

Grabbing the ticket. I aim to add docs and tests by the end of the weekend June 1-2.

Is there any reason why we shouldn't always include the prefix in the form kwargs?

    def get_form_kwargs(self):
        Returns the keyword arguments for instantiating the form.
        kwargs = {'initial': self.get_initial(),
                  'prefix': self.get_prefix(),

There shouldn't be any problems doing this, because the default prefix=None matches the default prefix=None in the form class. Always including prefix makes it easier to describe in the get_form_kwargs docs ("the prefix argument is set to get_prefix" than in the initial pull request, where prefix is only included if it evaluates to True.

comment:16 Changed 3 years ago by Gilberto Gonçalves <lursty@…>

Resolution: fixed
Status: assignedclosed

In ef37b23050637da643b47b1ee744702d4d603f4c:

Fixed #18872 -- Added prefix to FormMixin

Thanks @ibustama for the initial patch and dragonsnaker for opening the

comment:17 Changed 3 years ago by Marc Tamlyn <marc.tamlyn@…>

In 257a137c430cd325f3deeda8daffbf03a3cb20fd:

Merge pull request #1294 from LuRsT/added_prefix_to_form_mixin

Fixed #18872 -- Added prefix to FormMixin

comment:18 Changed 3 years ago by Tim Graham

In the release notes, this was added under "Backwards incompatible changes". I believe it should be under "Minor features" instead?

comment:19 Changed 3 years ago by Tim Graham <timograham@…>

In e10757ff4dbbc1aedd09df6c542948409c49d75f:

Doc cleanup for FormMixin.prefix; refs #18872.

Note: See TracTickets for help on using tickets.
Back to Top