I would like to propose five quite isolated improvements for
django.forms. But I think it is better to write about them in one
email - otherwise there would not be complete answers for the
problems. (More specifically, proposal 5 is very useful for proposals
1 and 2. And proposals 3 a 4 are very useful for proposal 5). And the
improvements have common motive - it should be very easy to write very
powerful and very flexible forms.
I want only write about syntax. I have working patches for them but I
don't say they are perfect or ready (for example only the first of
them has tests).
1. Ordering and filtering of fields, fieldsets
There would be three meta attributes for Form - fieldsets, fields and
exclude. These attributes would be set with inner meta class:
class FormX(FirstForm, SecondForm):
class Meta:
fields = 'first_A', 'first_B', 'second_A'
class FormY(FirstForm, SecondForm):
class Meta:
exclude = 'first_C',
class FormZ(FirstForm, SecondForm):
class Meta:
fieldsets = (
{'fields': ('first_A', 'second_A')},
{'legend': 'More information', 'fields': (''first_B',
'first_C')},
)
Attribute "fieldsets" would be a list of dictionaries. Each dictionary
could have item fields, legend and attrs.
Atribute "fields" would be a list of field names. It would be quite
similar as in the current model forms - but the attribute would also
specified ordering.
Attribute "exclude" would be a list of field names. It would have the
same semantics as in the current model forms.
There would be no change in Form._html_output. But there would be two
new methods in Form for templates - has_fieldsets and fieldsets. The
second method would be a iterator of dictionaries with items attrs,
legend and fields. Item fields would be a list of bound fields
specified by fieldsets meta attributes, other items would be relevant
meta attributes.
Patch: http://code.djangoproject.com/attachment/ticket/6630/00-fieldsets.diff
2. Inlines
There would be a new meta attribute for Form - inlines. And it would
be possible to use inline in meta attribute fieldsets:
class FormX(FirstForm, SecondForm):
class Meta:
fields = 'first_A', 'first_B', 'second_A'
inlines = InlineA, InlineB
class FormZ(FirstForm, SecondForm):
class Meta:
fieldsets = (
{'fields': ('first_A', 'first_B', 'second_A')},
InlineA,
InlineB,
)
(These examples are equivalent.)
Attribute "inlines" would be a list of formset classes. And these
classes could be a part of "fieldsets" attribute.
Form would not be able to construct inline formset instances.
ModelForm would construct inline formset instances through one to many
model fields.
Methods Form.full_clean, Form.media, Form.is_multipart, ModelForm.save
and FormSet.full_clean would be changed to support forms with inline
formsets.
There would be no change in Form._html_output. But method
Form.fieldsets would be changed to iterate two kinds of dictionaries -
the first variant (for fieldsets) would have items order (order of the
fieldset between fieldsets), attrs, legend and fields. The second
variant (for formsets) would have items order (order of the formset
between formsets) and formset (an inline formset instance).
Patch: http://code.djangoproject.com/attachment/ticket/6632/01-inlines.diff
3. Meta attribute formfield_kwargs for model forms
There would be a new meta attribute for ModelForm - formfield_kwargs.
It is a generalization of the "widgets proposal":
class CommentForm(forms.ModelForm):
class Meta:
model = Comment
fields = 'user', 'user_name', 'submit_date', 'comment',
formfield_kwargs = {
'user': {'queryset':
User.objects.exclude(is_superuser=True), 'attrs': {'class':
'important'}},
'user_name': {'help_text': 'for anonymous users'},
'submit_date': {'widget': SpecialDateWidget},
}
This meta attribute would be used as kwargs for
django.db.models.Form.formfield.
Patch:
http://code.djangoproject.com/attachment/ticket/9385/02-formfield-kwargs.diff
4. Attributes "attrs", "template" and "legend" for init methods in
forms
Forms and fields would have two new attributes for their __init__
methods - "attrs" and "template". Formsets would have three new
attributes for their __init__ methods - "attrs", "template" and
"legend". These attributes would not be used in Form._html_output -
but there would be saved and it could be possible to use them in
templates:
{% for field in forms %}
% if field.template %}
{% include field.template %}
{% else %}
<tr {{ field.attrs|flatatt }}>
<th>{{ field.label_tag }}</th>
<td>{{ field.errors }} {{ field }} {{ field.help_text }}</
td>
</tr>
{% endif %}
{% endfor %}
Patch:
http://code.djangoproject.com/attachment/ticket/9386/03-attrs-templates-legends.diff
5. Contrib application with form templates
There would be new contrib application with templates supporting all
previous proposals and also such improvements as css classes for
required fields or fields with errors. This application could be used
directly or as a pattern for someone's templates.
Patch:
http://code.djangoproject.com/attachment/ticket/9387/04-formtemplates.diff
But this patch is only a proof of concept. Is is equivalent of
Form.as_table and TabularInline. For example, real application should
be properly namespaced, should support equivalents of Form.as_ul,
Form.as_p and StackedInline (the last one with recursive inlines) and
should be extensible:
{% extends "parts/formset.html" %}
{% block formset-header %}
<tr class="header">
<th>First column</th>
<th>Second column</th>
</tr>
{% endblock %}
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
