Задать вопрос

Тел: +7 965 3737 888






<p>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.</p>
<p>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... - <a href="http://www.w3.org/TR/WCAG10-HTML-TECHS/#forms-grouping">Web Content Accessibility Guidelines 1.0</a> </p>
<p><strong>Notice</strong>: Since this uses <em>real</em> fieldset elements of HTML we had to define form.as_table the way it <em>includes</em> the table element around it.</p>
<p><strong>Usage in template</strong></p>
{{ form }}

<p>and <strong>not</strong> &lt;table&gt;{{ form }}&lt;/table&gt;</p>
<p><strong>Usage in view</strong> </p>
<p>Following usage example is for <em>django.contrib.flatpage</em>, 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</p>
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)

<p>Above creates two fieldsets:</p>
<ol><li>"None" named fieldset (meaning no name is given) with fields 'url', 'title' and 'content'.</li>
<li>"Advanced options" named fieldset with fields 'sites', 'template_name' and 'registration_required' and collapse class in place.</li>
</ol><p>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.</p>
<p>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.</p>
<p><strong>Some "counter" statemets for having this</strong></p>
<p><strong>S</strong>: "But I want to define the table tag myself in template!"
<strong>A</strong>: 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. </p>
<p>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.    <br></p>
<p><strong>S</strong>: "But, oh my! (newforms) admin does this already!"
<strong>A</strong>: For the <strong>last time</strong> this is not meant for only newforms admin, you can use this on <strong>any</strong> 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.</p>
<p><strong>S</strong>: "But, I want to use as_p, as_ul ..."
<strong>A</strong>: Go ahead and fix them below... Should be pretty easy stuff.</p>
<p><strong>S</strong>: "Each model should have only one fieldsets setting."
<strong>A</strong>: 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 <em>FieldsetForm</em> is not just having multiple fieldsets per model, it is about <em>where</em> and <em>how</em> to render them.</p>

Вопрос полезен? Да0/Нет0

Ответы (4):

Ответ полезен? Да0/Нет0

@Ciantic, umm, I wouldn't call my fork of WTForm maintained...

Ответ полезен? Да0/Нет0

Heh, I can't believe someone used this. I rediscovered this using Google.

I discarded this because it should be inbuilt to Django, and I don't mind upgrading these helpers too much.

Ответ полезен? Да0/Нет0

More changes in FieldsetForm to make it work

class FieldsetForm(BaseForm): metaclass = DeclarativeFieldsMetaclass

def __init__(self, *args, **kwargs):
    super(FieldsetForm, self).__init__(*args, **kwargs)
    self.fieldsets = None

Ответ полезен? Да0/Нет0

To make this work with django 1.0 wrap line 74 with mark_safe: mark_safe(u'\n'.join(output))

In addition it was not clear to me how to use it in my form, so here is an example:

class MyForm(FieldsetForm):

def __init__(self, *args, **kwargs):

    super(FieldsetForm, self).__init__(*args, **kwargs)

    self.fieldsets = ((None,{'fields': ('name1','email1')} ),
            ("Advanced options", {'fields': ('name1','email1'), 'classes':'collapse'})

name1 = forms.CharField(label="Name (1)")
email1 = forms.EmailField(label="E-mail address (1)")

name2 = forms.CharField(label="Name (2)")
email2 = forms.EmailField(label="E-mail address (2)")