On Oct 18, 6:44 pm, David Cramer <[EMAIL PROTECTED]> wrote: > Some of these changes I think are very valuable, especially CSS > classes. The formfield_kwargs I don't think is the right approach, but > possibly a method which could be called, as a lot of times I'm > overriding __init__ and it's quite messy, just to change the queryset > for a form.
I think that partial customization of forms can be divided to two groups: 1. Partial Customization which doesn't depend on current request - form class or form instances could be customized - it is specific for model forms (common forms has fields for it) - it can be solved with a "plain attribute" 2. Partial customization which depends on current request - only form instances could be customized - it is not specific for model forms - it cannot be solved with a "plain attribute" I think these two problems are very different. My proposal is for the first problem. > I would personally like to see every form row that's output using the > default methods be wrapped in a container, and have classnames for: > > - Errors > - If Required > - Widget Type (including parent type, excluding "Field") > > And, as_p should be as_div or some block element that can contain all > of this IMO also :) One of the main opinions behind the proposal is that is is very difficult to generate forms in python. It is complex now - for simple and not very flexible forms. But I think that forms should also support: - html class for row with required fields - html class for row with errors - html class giving type of field - html class giving type of widget - attributes specific for one (and only one) field row - complete customization of one (and only one) field row - fieldsets - legends for fieldsets - attributes specific for one (and only one) fieldset - complete customization of one (and only one) fieldset - inlines - legends for inlines - attributes specific for one (and only one) inline - complete customization of one (and only one) inline - recursive inlines I think it is almost impossible to do it in python. I tried it for fieldsets and inlines and I don't think it is good idea. It was very, very complex and it broke many tests. But there are templates for html code in django. So I propose to use _html_output only for simple forms (and for tests). And add contrib application which would support all these feature - by templates. Almost all html generators (for example Form.as_table, Form.as_ul, Form.as_p, BoundField.label_tag, Formset.as_table or ErrorList.as_ul) would not be used there - there would be only one exception "Widget.render" (because it is specific for each widget). It would be possible to use these templates directly. Or use them as "lego" for different default form. But it would be also possible customize exactly one "component" (form, field row, fieldset or formset) - only a little (by "attrs") or fully (by "template"). --~--~---------~--~----~------------~-------~--~----~ 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?hl=en -~----------~----~----~----~------~----~------~--~---
