Opened 17 years ago

Closed 13 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: dev
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@…> 17 years ago.
preview.2.diff (2.7 KB ) - added by Samuel Cormier-Iijima <sciyoshi@…> 17 years ago.
forgot to change done() parameter

Download all attachments as: .zip

Change History (7)

by Samuel Cormier-Iijima <sciyoshi@…>, 17 years ago

Attachment: preview.diff added

by Samuel Cormier-Iijima <sciyoshi@…>, 17 years ago

Attachment: preview.2.diff added

forgot to change done() parameter

comment:1 by Brian Rosner, 17 years ago

Version: newforms-adminSVN

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

comment:2 by Jeff Anderson, 17 years ago

Triage Stage: UnreviewedDesign decision needed

comment:3 by Bob Thomas, 16 years ago

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 by Luke Plant, 14 years ago

Severity: Normal
Type: New feature

comment:5 by Jacob, 13 years ago

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