Forms vs. Models: Redundant?
Ben Stahl
DRY principle? What I mean is, aren't we separately creating most or
all of the same fields for a form as for the model whose data will be
bound to the form? Why can't a form be instantiated automatically when
passed a model (maybe with flags for which fields are enabled)? Or
better yet, bind the form to a model (or model instance), which would
at all times keep the form fields in sync with the model. You could
have a parameter for each model field like form=True or whatever if
that field should be included in a form.
Maybe I'm not correctly understanding the relationships here though,
or missing something. Sorry if that's the case, I am new at Django,
but so far I love it.
Tim Chase
> model (maybe with flags for which fields are enabled)? Or
> better yet, bind the form to a model (or model instance),
You mean like:
django.newforms.models.form_for_model
django.newforms.models.form_for_instance
I'm not sure where I stumbled across this first as I didn't find
it in the djangoproject.com docs, but it's clear that you're not
the only one to think this. :)
There is a separation (and so Django provides it) as you might
want a form that incorporates more or less than a model, but if
it's just a model that you want, these shortcuts eliminate some
of the grunt-coding.
> You could have a parameter for each model field like
> form=True or whatever if that field should be included in a
> form.
You don't get this much, but you at least get a shortcut for
building forms from a model/instance. Additionally, modifying
the model would not be desirable, as you might want to have
different views/forms of the same model (and such tagging could
conflict).
-tkc
TaMeR
I been trying to figure this out too.
In the admin site the forms show up automatically and if you set
something like <code> auto_now_add=True</code> then the field is
hidden which is nice. Why can't this be implemented on the frontend as
well?
TaMeR
On Mar 27, 2:36 pm, Tim Chase <django.us...@tim.thechases.com> wrote:
> django.newforms.models.form_for_model
> django.newforms.models.form_for_instance
Is there a example use for this somewhere? I am new ...
Tim Chase
>> django.newforms.models.form_for_instance
>
> Is there a example use for this somewhere? I am new ...
You can find some demo code at
http://www.djangosnippets.org/tags/form_for_model/
And as always, it's just Python, so you can read the code in
django/newforms/models.py to read the docstring(s), and see just
what it does.
-tkc
dbal...@gmail.com
that bound the forms and models together (a little like
form_for_model, but handles multiple 1-1 models). I thought it would
save me a lot of time, but looking back I've only been able to use it
on a few forms. I think the decision to keep them separate is really
for the best. It's a few more lines of code, but everything is clear
and very flexible. You just have to override the init and save
methods on the form to handle your models. This post in django-users
was helpful for that: "Newforms practice (common situation)" You
control all the interaction, and there aren't any smoke and mirrors.
There isn't anything keeping you from using the model definitions to
dynamically build the form and save in init if you really want to
(that's what I did). It's really revealing to look at the
form_for_model function code. It's amazingly short (like 15 lines or
so), and should give you a good idea of how to do it. It's probably a
really bad idea though because you could be in for a painful divorce
if they change the model implementation much.
Adrian Holovaty
Patience, TaMeR, patience. :)
The form_for_model and form_for_instance functions, which Tim Chase
mentioned earlier in this thread, are not yet documented (or 100%
complete).
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
Tim Chase
> mentioned earlier in this thread, are not yet documented (or 100%
> complete).
Ouch...no wonder they're not documented yet ;) Glad I haven't
had any fiascoes. I guess I would deserve any abuse Django gave
me if there were problems, for using undocumented (and
incomplete) features. Though perhaps any breakage I encountered
would allow me to contribute to Django on company time.
-tkc
Malcolm Tredinnick
Along with the other answers you've received about using
form_for_instance and form_for_model, I'd like to point another piece of
design logic behind newforms (and even oldforms). This is purely
informational and maybe you already realise it:
It's not always the case that a form consists of data for only one
model. In my own experience, the forms I build collect data that is
ultimately split between multiple models and/or the form fields are
munged prior to being insert into a model -- for example, a
comma-separated list of strings becomes multiple tag instances in the
database.
This sort of usage isn't something that I see discussed on this list a
lot (the splitting tags is, but data -> multiple forms isn't), which
makes me think that by the time you need that, form processing isn't
that hard, or it isn't that common (I suspect the former). Tying form
creation any more tightly to models that via the utility methods already
provided would make the more generic form usage style a bit harder.
Regards,
Malcolm