It's just an extension for the admin. Replace the collapse.js (collapse.min.js) and use it like this in the admin fieldset option: ´´**'classes': ['collapse', 'open']**´´. Without the 'open'-class, it will work as usual. *Needs possibly fixing for IE <= 8* because IE doesn't support the ´´:not´´ selector.
FieldStack simplifies forms template rendering. This is enhanced version of snippet [1786](http://djangosnippets.org/snippets/1786/)
This snipped removes a specific fields from the fieldsets. This is very useful to leave a field 'out' in the admin, likewise: def get_fieldsets(self, request, obj=None): fieldsets = super(BlaModelAdmin, self).get_fieldsets(request, obj) if not request.user.has_perm('change_blah'): remove_from_fieldsets(fieldsets, ('blah',))
This snippet was inspired by [1783](http://www.djangosnippets.org/snippets/1783/). It allows simply create groups of fields for template rendering.
With this, you can group form fields very easily. Since it does not create any html, you can use it not only to create fieldsets (with tables, lists, etc).
**NOTE**: Further development of this snippet will take place in the [django-form-utils](http://launchpad.net/django-form-utils) project. This snippet provides BetterForm and BetterModelForm classes which are subclasses of django.forms.Form and django.forms.ModelForm, respectively. BetterForm and BetterModelForm allow subdivision of forms into fieldsets which are iterable from a template, and also allow definition of row_attrs which can be accessed from the template to apply attributes to the surrounding container of a specific form field. It's frequently said that a generic form layout template is a pipe dream and in "real usage" it's necessary to manually layout forms, but in my experience the addition of fieldsets and row_attrs, plus a competent CSS designer, make it possible to create a generic template that can render useful production form markup in 95+% of cases. Usage: class MyForm(BetterForm): one = forms.CharField() two = forms.CharField() three = forms.CharField() class Meta: fieldsets = (('main', {'fields': ('two',), 'legend': ''}), ('Advanced', {'fields': ('three', 'one'), 'description': 'advanced stuff'})) row_attrs = {'one': {'style': 'display: none'}} Then in the template: {% if form.non_field_errors %}{{ form.non_field_errors }}{% endif %} {% for fieldset in form.fieldsets %} <fieldset class="fieldset_{{ fieldset.name }}"> {% if fieldset.legend %} <legend>{{ fieldset.legend }}</legend> {% endif %} {% if fieldset.description %} <p class="description">{{ fieldset.description }}</p> {% endif %} <ul> {% for field in fieldset %} {% if field.is_hidden %} {{ field }} {% else %} <li{{ field.row_attrs }}> {{ field.errors }} {{ field.label_tag }} {{ field }} </li> {% endif %} {% endfor %} </ul> </fieldset> {% endfor %}
Syntax: `{% get_fieldset list,of,fields as new_form_object from original_form %}` Example: {% load fieldsets %} ... <fieldset id="contact_details"> <legend>Contact details</legend> <ul> {% get_fieldset first_name,last_name,email,cell_phone as personal_fields from form %} {{ personal_fields.as_ul }} </ul> </fieldset> <fieldset> <legend>Address details</legend> <ul> {% get_fieldset street_address,post_code,city as address_fields from form %} {{ address_fields.as_ul }} </ul> </fieldset>
This template tag build a Form splitted in fieldsets. The fieldsets are configured with a second parameter, that is a tuple like the one used in the Admin class in models in the attribute "fields". You pass to the template the form and the tuple and than use them as parameters for the templatetag. You can take a look at the source and modify It to build forms the way you like. It is very useful If you do not like the way Django build forms with the methods as_p, as_ul or as_table and also do not like to write html by hand.
WTForm is an extension to the django newforms library allowing the developer, in a very flexible way, to layout the form fields using fieldsets and columns WTForm was built with the well-documented [YUI Grid CSS](http://developer.yahoo.com/yui/grids/) in mind when rendering the columns and fields. This should make it easy to implement WTForm in your own applications. Here is an image of an [example form rendered with WTForm](http://www.gmta.info/files/wtform.png).
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.
10 snippets posted so far.