Defining newforms fields at runtime

[sime <simon@…>]

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()

[sime <simon@…>]

provides forms.new_form()

[sime <simon@…>]

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

[sime <simon@…>]

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()

[Marc Fargas <telenieko@…>]

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 ;))

[Chris Beaven]

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.

[sime <simon@…>]

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.

[Chris Beaven]

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.

[Malcolm Tredinnick]

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.