I agree and disgree. :)
I like James Bennetts's example a lot, but I'd like it more if the form
class were ModelForm, descending from a more general Form class that
would look much like the base Manipulator class of today.
I'm afraid that I find the idea in Brantley Harris's proposal of
raising a Form as an exception as a form of flow control really
counter-intuitive. Apologies and it's just my opinion of course, but it
has a sort of "too clever" feel to me. Also, exceptions are very
expensive, and I don't see the practical benefits of that usage pattern
over something like:
form = Poll.CreateForm(request)
errors = form.validate()
if errors:
...
else:
...
Last up, a question for James. In your example you have exclude_fields
and extra_fields. What if I want to bind a different form field type to
a model field? What would the synax be for that? Something like:
class CrazyArticleForm(ArticleAddForm):
override_fields = ( myapp.CrazyField(field_name='title',
model_field='title', )
Maybe? (I don't like 'override' there but I'm not sure what else to
call it.) And in service of that sort of thing, I think at the input
conversion phase, the form should delegate to each field to pull its
data out of the request, since some fields may be singular in concept
but spawn multiple html elements.
That brings up a related question: can one form field bind to multiple
model fields? (I'm thinking of file upload, where you get can back a
filename and a mime type and the file contents).
JP
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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-developers
-~----------~----~----~----~------~----~------~--~---
