On Thu, Jun 3, 2010 at 7:41 PM, petr.marhoun <petr.marh...@gmail.com> wrote:
> Hello,
>
> I would like to propose some improvements for django.forms. But it is
> seven quite independent proposals - one mail would be to long, seven
> emails would too many emails. So I have created wiki page - is it a
> good procedure?
It's not really ideal, because it makes the initial phases of much
harder. Starting a wiki page is a good idea when you have a single,
very complex idea, and you want to track the evolution of planning.
However, if you have lots of little ideas, you would be better served
with a single email so that we have something to hang the discussion
on.
That said, here's some initial feedback:
1. Fieldsets
This is effectively just exposing an Admin capability into general
forms; I'm +1 to this general idea.
One complication I can see is how to handle iteration. "for field in
form" currently assumes that all the fields are ungrouped. How does
this change when fieldsets are introduced? Does iterating over the
form give you fieldsets, which are themselves iterable? Do you need to
iterate over "for fieldset in form.fieldsets", with "for field in
form" iterating over the raw fields independently of the fieldsets?
I'm also not entirely clear how we can/should implement this with BaseForm.
So - more detail required, but generally +1 from me.
I would also point out that one of the acceptance criteria for this
proposal should be backporting the changes into Admin. Admin should be
the best example of us eating our own dogfood; however, the tools in
admin have a habit of evolving on their own a little bit too much. If
this give us an opportunity to do some of this housekeeping, I'd call
that a big win.
2. Inlines
I'm not sure I see the benefit of this. Why does inline processing
need to be crammed into the base form?
3. Better API for formsets
Formsets are complex beasts, to be sure. However, I'm extremely wary
of proposals that advocate widespread changes to existing API.
Backwards compatibility will be a *huge* issue here - however broken
the current implementation may be, we can't change the conditions
under which forms validate at present.
That said, I'm sure there are validation edge cases that can be
legitmately called bugs, and that aren't tested at the moment. If
cleaning up the formset API allows us to fix those edge cases, all the
better.
So - a tentative +0 to this idea, but most of the effort will be in
proving that you're fixing bugs, not breaking features.
4. Model fields with not-default values
Isn't this mostly what the new widget Meta argument does?
5. Parameters "template" and "attrs" for forms, formsets, fieldsets,
forms, (bound) fields and widgets
6. Support for (X)HTML5 and legacy HTML
I strongly suspect that these two may be covered by something I
discussed with Jacob at DjangoCon. Broadly, the proposal is to
deprecate the {{ field }} and {{ form }} approach to template
rendering in favor of a template tag {% render field %} and {% render
form %}; these template tags would allow you to customize the way that
individual fields, fieldsets and forms are rendered, including
controlling doctype compliance.
If you want to override the way fields or forms are rendered, you will
be able to subclass the base render template tag, override the
rendering behavior, and re-register the tag (or register it under a
different name).
I've been tinkering with this since DjangoCon.eu; I hope to be able to
present something once I surface from jetlag and the backlog of mail
and other tasks in my inbox.
7. Requests in forms
I suspect the answer on this one will be no for the simple reason of
backwards compatibility. A request attribute is only really useful if
it is ubiquitous, and there's no way to make it ubiquitous without
breaking backwards compatibility. Truth be told, having the request
around would have made CSRF a lot easier, but it wasn't so we had to
fall back on {% csrf_token %}.
This is also something that can be implemented in user-space by
subclassing a form and enforcing the request argument. So, call this a
-0 from me.
There's some brief feedback. My one additional request is to try not
to be too ambitious. You've proposed a lot of work here; frankly, if
you only got (1) finished for 1.3 I would consider it to be a major
win.
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-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
