> The short answer to your problem is probably to not use form_for_model()
> if you want this sort of support. Instead write your own Form sub-class
> and write a clean() method for it. The form_for_model() function is just
> an aid after all; it shouldn't be the only thing you ever consider
> using.
OK.... I think I'm also not entirely clear on the difference between
creating a completely separate Form class vs. extending BaseForm and
using form_for_model() -- the implications of each option, what does
and doesn't have to be done for each, and when each is preferable.
> There's a "division of labor" problem going on in the case you are
> looking at. Forms are orthogonal to models. It just happens that in this
> case, accidentally, your form has a correspondence between its fields
> and one of your models, but in the entire universe of possible forms and
> possible models, that correspondence can't be assumed.
You're right, it is orthogonal. I suppose form_for_model() really
exists in order for basic forms to be available for all models in the
admin, and it's just exposed to other apps for the sake of
convenience?
> [Aside: it seems that Django projects split into two rough groups --
> those whose forms are in close correlation to their models and those
> whose forms map the data onto different fields in different models after
> lots of munging; I never seem to write the first type of app, for
> example, so form_for_model is something I don't find myself needing at
> all.]
Yup, I've got an app of the second type coming up, but I'm working on
one of the first type in an attempt to become familiar with newforms.
> So a "uniqueness" constraint on your model is not something that the
> form framework is really in a position to check. Instead, what should
> happen is you construct the model object and then call
> object.validate(), which returns ValidationErrors if there are problems.
> The validate() method on a model will have full access to the model
> instance (including "self").
Do you then have to figure out which errors apply to which Form
fields, and sort them out and assign them? I haven't seen any sample
code doing anything of this sort, so I'd be very interested to see how
it works.
I have to say, I'm incredibly impressed with Django, with all the
functionality it provides, and with the way it's moving so quickly.
Newforms, in particular, reminds me of something I was beginning to
build into my personal PHP library, and I recognize that it's a
boatload of work to make something that everyone can use. I can't
wait until the documentation catches up with the development!
> Am Dienstag, 29. Mai 2007 21:19 schrieb ringemup:
> you can add custom validation methods to the class (either by subclassing
> or by adding a bound method)
>
> Example: ("file" is the attribute of the form/model)
>
> def clean_file(self):
> value = self.fields["file"].widget.value_from_datadict(self.data,
> self.add_prefix("file"))
> if not ...:
> raise forms.ValidationError(u"...")
> return value
That sounds like a reasonable solution. Two questions: how does one
add a bound method (in fact, what is a "bound method")? Also, how
does one subclass a class that is created dynamically with
form_for_model()?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
