Hi Adrian
On the whole, this looks like pretty good stuff to me. A few comments
along the way; some of these ideas need not be in the v1
implementation, but I mention them anyway so that we don't roll out a
system that can't accomodate them in the future:
On 9/13/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote:
>
> As an alternative, my proposal has two main classes: Form and
> BoundForm.
I'm with Jacob on having a single Form class, with the bind method
used to associate data.
All the examples you have provided only use the Form instance as a
factory for producing the BoundForm instance. Is there any other
reason that you would need an unbound Form? If so, is there any reason
that the functionality on an unbound Form() would be different to
BoundForm? Isn't an unbound form the same as a form that is bound to
nothing? In which case, why not specify the binding dictionary at time
of construction (empty, if you don't want any binding)?
> Note that this is nice and terse but comes slightly at the expense of
> efficiency, as both form.is_valid() and form.bind() perform
> validation.
Wouldn't the following:
form = ContactForm().bind(**request.POST)
# or maybe form = ContactForm(**request.POST)
if request.method == 'POST' and not form.errors()
send_email_and_redirect()
return render_to_response('email_form.html', {'form':form})
be almost equivalent to your terse version, but avoid the inefficiency
of two calls to validate? It would require 1 call to validate in the
'empty form' case, but that could be immediately shortcut as 'if not
_kwargs: return false` (and it's implicitly made by the form.bind()
call on the last line of your example, anyway).
> There are two differences here:
>
> 1. form.sendername.errors.as_url rather than
> 2. "form.sendername.as_text" rather than "form.sendername". I'm not
+1 to providing the ability to select a widget at the template level,
but -1 to requiring .as_text for the default case. Similarly -1 for
errors.as_ul. Two reasons:
1) Minimizing the migration task for existing templates
2) I can't think of a data types that doesn't have a reasonable
default widget (as evidenced by the existing Forms setup). Allowing
easy access to a non-default widget would be great, but the default
widget suffices in all existing cases, and should be easy to specify
in the field definition itself.
On this note, is there an opportunity here to handle the 'this form
field requires foo.js' issue? The admin system currently has a
mechanism for gathering JS requirements; it would be nice if something
like {{ form.includes }} would output all the javascript includes
required by the fields on the form (although there are some
interesting intersections between allowing different field renderings
and knowing which JS includes are required).
> Let's change this to be similar to model classes, like so:
+1
Some other issues that come to mind:
- Handling of related objects; in particular, select widgets for
reverse m2o/m2m relations. I presume that you are looking at using an
`authors = form.SelectField()` type arrangement for handling m2m
relations? Does this approach allow for reverse m2o/m2m fields to be
in the default form for a model? (I'm fairly certain it does, but I
thought I'd check)
t- Handling of 'inline edited' objects. I, for one, would like to see
core/edit_inline removed from the model definition; for me, this is a
form rendering issue. How do you see inline forms being handled in
this setup? I seem to recall there was talk of 'recursive forms' at
one point, rather than the data-flattening approach currently used.
Yours,
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
