Opened 17 years ago

Closed 17 years ago

#4384 closed (wontfix)

Defining newforms fields at runtime

Reported by: sime <simon@…> Owned by: Adrian Holovaty
Component: Forms Version: dev
Severity: Keywords:
Cc: Triage Stage: Design decision needed
Has patch: no Needs documentation: yes
Needs tests: yes Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

I need to be able to define forms entirely at runtime (fields, choices, etc). Using form_for_xxx is fine, because it returns a class which you can manipulate using base_fields before initialising.

Rather than use type(..) which seems messy, I've added the simple function to newforms. It returns a form class based on any given form class (Form itself by default).

Example --

DynForm = forms.new_form()
DynForm.base_fieldsbla = ...
form = DynForm()

Or for manipulating a form you've already defined elsewhere --

SpecialForm = forms.new_form(StandardForm)
SpecialForm.base_fieldsbla = ...
form = SpecialForm()

Attachments (2)

empty_form.diff (600 bytes ) - added by sime <simon@…> 17 years ago.
provides forms.new_form()
new_form.diff (620 bytes ) - added by sime <simon@…> 17 years ago.
oops I renamed it, think I like the new_form name slightly better

Download all attachments as: .zip

Change History (8)

by sime <simon@…>, 17 years ago

Attachment: empty_form.diff added

provides forms.new_form()

by sime <simon@…>, 17 years ago

Attachment: new_form.diff added

oops I renamed it, think I like the new_form name slightly better

comment:1 by sime <simon@…>, 17 years ago

Example --

DynForm = forms.new_form()
DynForm.base_fields['bla'] = ...
form = DynForm()

Or for manipulating a form you've already defined elsewhere --

SpecialForm = forms.new_form(StandardForm)
SpecialForm.base_fields['bla'] = ...
form = SpecialForm()

comment:2 by Marc Fargas <telenieko@…>, 17 years ago

Needs documentation: set
Needs tests: set

At least it misses tests and docs. Maybe a triager can later set "Design Decission Needed" or "Accepted".

the improvement itself seems useful, you can include an example of the current aproach with type() to emphatize the improvement ;))

comment:3 by Chris Beaven, 17 years ago

Triage Stage: UnreviewedDesign decision needed

I'd suggest you could just override the __init__ method (before calling super(...).__init__) and do the base_fields building work in there.

Alternately, you could just change form.fields after initialising.

Call me -0.5 because there are other ways to do this already, but I'll let a committer decide.

comment:4 by sime <simon@…>, 17 years ago

Yes, but using either init or .fields means you have to write a near empty class for nothing. It's ugly.

Also, could well be wrong on this one, but manipulating .fields after initialisation didn't seem to work properly for me. Might try that again some time.

comment:5 by Chris Beaven, 17 years ago

I was thinking that you could do the work in the __init__ function itself (passing the appropriate parameters), so it wouldn't really be near empty. It was just one idea.

Regarding using .fields, you could just use BaseForm itself.

comment:6 by Malcolm Tredinnick, 17 years ago

Resolution: wontfix
Status: newclosed

This is only adding another way to do something that is already possible with either a new metaclass or subclassing, depending on circumstances and preference. Not worth including in core, for that reason.

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