This is FieldsetForm for rendering forms with fieldsets. This is not in anyway final version of this snippet. This is preliminary version which just works. One can easilly implement the `as_ul`, `as_p` at the end with just looking the `as_table` definition.
> Content developers should group information where natural and appropriate. When form controls can be grouped into logical units, use the FIELDSET element and label those units with the LEGEND element... - [Web Content Accessibility Guidelines 1.0](http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-grouping)
**Notice**: Since this uses *real* fieldset elements of HTML we had to define `form.as_table` the way it *includes* the `table` element around it.
**Usage in template**
{{ form }}
and **not** `<table>{{ form }}</table>`
**Usage in view**
Following usage example is for *django.contrib.flatpage*, but naturally you can use it to whatever you want. Example assumes user knows about newforms and basics to how to use `form_for_*` functions
from THIS-SNIPPETS-POSITION-IN-PYTHON-PATH import form_fieldsets
...
fieldsets = form_fieldsets(
(None, {'fields': ('url','title','content',)} ),
("Advanced options", {'fields': ('sites', 'template_name', 'registration_required',), 'classes':'collapse'})
)
...
... forms.models.form_for_instance(flatpage, **fieldsets)
... forms.models.form_for_model(FlatPage, **fieldsets)
...
Above creates two fieldsets:
1. "None" named fieldset (meaning no name is given) with fields 'url', 'title' and 'content'.
2. "Advanced options" named fieldset with fields 'sites', 'template_name' and 'registration_required' and collapse class in place.
Syntax of form_fieldsets function is identical with models `class Admin: fields = (...)`, actually you can use admins exact line here with adding it like `form_fieldsets(*FlatPage.Admin.fields)` if you prefer that, although it wrecks the point of having newforms admin, if one does identical forms as in admin part. Purpose of this is not to create identical forms as in admin but to provide easy fieldsets for all views and forms.
To follow DRY principle this should be part of Django and Django's newforms-admin branch should start to use some subclassing of this. But even if the newforms-admin branch never take this in, it is more DRY than without to use this in own projects, with this in place you can forget all template hazzles defining fieldset manually.
**Some "counter" statemets for having this**
> **S**: "But I want to define the table tag myself in template!"
**A**: Well, you understod something wrong;
First of all, for example, if there is something missing from the output of this table tag, you can feel free and subclass from FieldsetForm and define own as_table.
Second of all, for having own table tag there can be only one reason to that, you want extra arguments, and that is TODO, but it is also easy piece. I haven't just needed extra stuff yet so they are not implemented.
> **S**: "But, oh my! (newforms) admin does this already!"
**A**: For the **last time** this is not meant for only newforms admin, you can use this on **any** given view or form renderition, since currently django does not give a simple way to use that handy fieldset automation in own views. And currently (9th of April, 2007) newforms admin does not do it this way.
> **S**: "But, I want to use as_p, as_ul ..."
**A**: Go ahead and fix them below... Should be pretty easy stuff.
> **S**: "Each model should have only one fieldsets setting."
**A**: I don't believe that; even if I did that is not convincing, since there are views that are not based on models, just bunch of fields, how would you define their fieldsets if it is not defined in the form renderition at the first place? This is the right place to define fieldsets. And the point of *FieldsetForm* is not just having multiple fieldsets per model, it is about *where* and *how* to render them.