Opened 9 years ago

Closed 5 years ago

#7222 closed New feature (wontfix)

FormPreview should pass the form to done()

Reported by: Samuel Cormier-Iijima <sciyoshi@…> Owned by: nobody
Component: contrib.formtools Version: master
Severity: Normal Keywords: formpreview done cleaned_data form
Cc: sciyoshi@…, bthomas@… Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Currently, FormPreview's done() gets passed the request and the form's cleaned_data, but it'd be much nicer if done() got passed the actual form instead. This way, for ModelForms, one could just do form.save(). You can still get the cleaned_data with form.cleaned_data. Attaching a patch that breaks backwards compatibility, but I think its nicer in the long run...

Attachments (2)

preview.diff (2.3 KB) - added by Samuel Cormier-Iijima <sciyoshi@…> 9 years ago.
preview.2.diff (2.7 KB) - added by Samuel Cormier-Iijima <sciyoshi@…> 9 years ago.
forgot to change done() parameter

Download all attachments as: .zip

Change History (7)

Changed 9 years ago by Samuel Cormier-Iijima <sciyoshi@…>

Attachment: preview.diff added

Changed 9 years ago by Samuel Cormier-Iijima <sciyoshi@…>

Attachment: preview.2.diff added

forgot to change done() parameter

comment:1 Changed 9 years ago by Brian Rosner

Version: newforms-adminSVN

This has nothing to do with newforms-admin. :)

comment:2 Changed 8 years ago by Jeff Anderson

Triage Stage: UnreviewedDesign decision needed

comment:3 Changed 8 years ago by Bob Thomas

Cc: bthomas@… added

I agree that this would be useful. In comparison, the form wizard passes a list of form instances to its done() method. This would bring a little more consistency to formtools.

I had some issues with using cleaned_data instead of the form, but I was able to hack around them by putting some completely inappropriate data in cleaned_data.

If this is accepted, should it go into 1.0? It seems that it would be better to break backwards compatibility now rather than after 1.0.

comment:4 Changed 6 years ago by Luke Plant

Severity: Normal
Type: New feature

comment:5 Changed 5 years ago by Jacob

Easy pickings: unset
Resolution: wontfix
Status: newclosed
UI/UX: unset

Yeah, we clearly missed getting this in before 1.0!

Adding it now would indeed introduce a backwards-incompatible change, and I can't see a good way around that. Thus, marking wontfix: the slight improvement in usability doesn't warrant breaking everyone's existing code.

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