On Thu, Jun 3, 2010 at 11:32 PM, petr.marhoun <petr.marh...@gmail.com> wrote:
> 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.
Admin contains all sorts of functionality; but one of the pieces of
functionality is a fieldset implementation. What I'm saying is that
rather than building *another* fieldset implementation, we should
either factor the admin implemetnation into the core forms library, or
we should replace the admin implementation with a new implementation
that is added to the core forms library.
I don't doubt that admin will require additional customization -- but
making sure that it is possible to add that customization is a core
part of your design task. If you can't provide a base implementation
that admin can subclass and extend to meet it's needs, then you
probably don't have a viable proposal for an API.
To my mind, the ultimate goal is that admin should be little more than
a relatively minor customization of the builtin form, formset and
generic view capabilities of Django core.
>> 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?
Ok - so again; abstract out some of the utilities from admin to make
the validation and error combining process easier. I don't see any
reason why we need to try and cram inline objects into the base form
object; we just need better tools for asking the "if this object, or
any of it's related objects are invalid" type questions.
>> 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.
Like I said, a tentative +0, which is completely dependent on the
implementation demonstrating that it is backwards compatible. It's
very easy to *say* your approach will be backwards compatible -- take
it from personal experience that it's often much harder in reality.
> 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.
As soon as you make the parameter optional, it ceases to be
ubiquitous, which significantly reduces it's usefulness. The only way
I can see around this is to introduce a "RequestForm", but I'm not
sure if I'm wild about the idea of complicating the decision about
which form base class you should use.
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.
