On Jun 3, 2:57 pm, Russell Keith-Magee <russ...@keith-magee.com>
wrote:
> 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.
OK, more details: If fieldsets would be defined, fields would be
concatenation of fields from individual fieldsets. So methods
as_table, as_ul and as_li and "for field in form" would work as now.
But if you want to really use fieldsets, you have to iterate fieldsets
in your templates.
I think I am able to implement it - but the first step is to decide
what to implement.
> 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.
Yes, it is difficult. I think that admin has one kind of functionality
(not only forms, but also for example pagination, ordering or
filtering) in too many places (model admin, helper methods and
classes, templates, template tags ), it could be encapsulated in one
class. But I do not think that it is possible to change without
breaking backward-compatibility. So for forms and fieldsets I would
propose only extract meta attributes of forms as class attributes of
model admin.
> 2. Inlines
>
> I'm not sure I see the benefit of this. Why does inline processing
> need to be crammed into the base form?
Because I want to edit object including related objects. So the
object's form is valid if all inlines are valid. And saving the
objects means to save all inlines.
Yes, it is possible to iterate all inlines and decide if they are
valid and then save them once by once - but I thing it is very common
activity and it should be in core forms. And what if I want to edit my
objects with general views (for example class model views which could
be in 1.3)? How should I tell the general view I want to edit also
related objects?
> 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.
Current API for using of validated formsets is:
- cleaned_data - I think that this property is broken by design
because valid formsets can have invalid forms without cleaned_data (if
they should be deleted).
- deleted_forms - it is useful as it is.
- ordered_forms - it is useful as it is but it would be redundant if
there would be more general property working also with unordered
formsets.
And there is no API for the my main requirement: give me all filled
and valid forms and nothing more, possible ordered (if can_order is
True). I propose new property which give me these forms.
So my proposal in other words:
1. Simplify formset validation with full backward-compatibility (minus
bugs).
2. Add new property "cleaned_forms" which do the right thing.
3. Possible deprecate "ordered_forms" (because it is redundant).
4. Possible deprecate "cleaned_data" (because it is broken by design -
there is note in code: "# Maybe this should just go away?").
> 4. Model fields with not-default values
>
> Isn't this mostly what the new widget Meta argument does?
The new widget meta argument does it for one specific case. My
proposal is general for all keyword arguments. It is possible to add
more and more meta arguments (help_texts and labels and so on) - but
is it a good idea? And there could be some arguments specific for only
one type of fields, they need general method for setting of not-
default value.
> 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.
I think it should not be backward-incompatible - init of forms and
formsets would have last argument requiest with default value None. So
current code will continue to work.
But I fully agree that it could be solved by subclass which would save
the request. But if it will be quite common for init methods to accept
request arguments, new generic views could set this argument.
Otherwise everybody who would like to use request in forms and generic
views has to subclass forms and generic views, they could not be
enhanced independently.
> 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.
