On Thu, 2007-07-12 at 15:40 -0500, Adrian Holovaty wrote:
> On 7/12/07, Todd O'Bryan <[EMAIL PROTECTED]> wrote:
> > Is there a good reason not to do something like the following in
> > django.db.models.Model?
> >
> > def form(self):
> > return form_for_instance(self)
> >
> > @classmethod
> > def form(cls):
> > return form_for_model(cls)
>
> Yes -- the good reasons against it are that it ties form logic to the
> model and quashes the field namespace (disallowing you from having a
> field named "form").
How separate do you intend the models and forms to be? As it stands
right now, forms can have validators, but if you actually want to
validate programmatically what you're doing to the database, you have to
repeat any validation code you put in the form somewhere in your model.
For example, I'm storing ISBNs. They have a check digit. I can write a
nice ISBN validator that checks the check digit, but I have to attach it
to the form *and* figure out somewhere to call it in the model to be
sure illegal ISBNs don't get stored to the database. If I ever get
around to trying to check forms client-side, I'll need to supply that
information in a third way. (Ignore briefly the fact that client-side
validation would have to be in JavaScript.)
The thing that's annoying is that this is really an attribute of the
model. It's a fact about the data, not a fact about the form, which is
just a way to view and modify the data.
form_for_instance and form_for_model are great, but if you have to tweak
the form in any way (say you want to use a non-default widget for one of
the data fields) and want to use it more than once, you're reduced to
defining a new Form class or at least a new callback function to control
the field types. And where do you put that? For me, it's pretty clearly
an attribute of the model in the same way that a utility method would
be, because it just doesn't have any meaning without the model. So you
put it in the model.
This may be heresy, but I have to put it out there:
Why not just admit that models are often manipulated by forms and
provide support for things like validators and form fields in the models
themselves. What would be so wrong with:
class Book(models.Model):
isbn = models.CharField(maxlength=13,
form_field=forms.CharField(
widget=forms.TextInput(attrs={'size':'13'})),
validator = isbn_validator)
...
or even better, perhaps,
class Book(models.Model):
isbn = models.CharField(maxlength=13,
widget_attrs={'size':'13'},
validator=isbn_validator)
...
Obviously it would be possible to ignore the form tie-ins completely.
You would still need form validators that aren't tied to models, and
would still have the ability to create forms that were tied to the model
but different from the ones that the model fields specified, but you'd
get to specify all the stuff about your data (including, I'll admit, a
little bit about the data's presentation, but note that that's
completely optional and you're not obligated to do it) in one place.
On the other hand, as has happened several times before, maybe I'm
making this way more complicated than it needs to be because I'm missing
some little piece of code that would make all of this much less
disjointed.
OK...feel free to berate me. :-)
Todd
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~----------~----~----~----~------~----~------~--~---
