Hello,
> One thing form-utils does differently from your proposal is that it
> defines each fieldset as a two-tuple (like admin fieldsets), with a
> name as the first element and the dictionary of additional info as the
> second element. One advantage of having a fieldset "name" is that it
> also allows accessing fieldsets individually in the template, for more
> fine-grained layout control (thanks Rob Hudson for adding this to form-
> utils).
>
> Just to give a full summary of the fieldsets API I would propose
> (which is not exactly the same as what's currently in form-utils; I'd
> like to correct some mistakes :> ):
>
> class PersonForm(forms.Form):
> name = forms.CharField()
> age = forms.IntegerField()
> nickname = forms.CharField()
>
> class Meta:
> fieldsets = [('main', {'fields': ['name', 'age']}),
> ('extra', {'fields': ['nickname'],
> 'legend': 'Extra info',
> 'classes': ['aside']})]
I tried to be minimalistic and to give template authors only iterator
- but I like this proposal more.
I have some notes to forms-utils:
- The code says: "if legend is None: legend = name". I dislike it - I
want to have possibility not to set legend. I think that if legend is
not set it should be "None" in fieldset.
- It seems that it is not possible to say if form has fieldsets
(fieldsets method even construct fieldsets if meta attribute is not
set) - I think it is useful to know it in templates.
> (If "fieldsets" is provided for a ModelForm, it takes priority over
> any "fields" or "exclude" definitions: the fields included in the
> fieldsets are the ones included in the form, whether you iterate over
> fieldsets or just fields.)
It is the same as I tried to describe - so I agree.
> Iterating over the form directly yields BoundFields just as it does
> now:
>
> {% for field in form %}
>
> Iterating over form.fieldsets yields Fieldset objects. Fieldset
> objects can be iterated over to yield BoundFields:
>
> {% for fieldset in form.fieldsets %}
> {% for field in fieldset %}
>
> Fieldsets can also be accessed individually by name on form.fieldsets:
>
> {% for field in form.fieldsets.main %}
>
> And fields can be accessed directly by name on the "fields" attribute
> of a Fieldset (to avoid clashes between form field names and other
> Fieldset attribute names):
>
> {% form.fieldsets.main.fields.age %}
>
> Fieldset objects also have the attributes "name", "legend", and
> "classes" (which is still an iterable, not collapsed to a string, so
> template authors can check {% if "blah" in fieldset.classes %} if
> needed.
>
> I am proposing the "classes" option, again parallel to current admin
> fieldsets, in lieu of any additional options like "attrs" or
> "template". There's a slippery slope where almost any info _could_
> theoretically be provided for the template author by the Python form
> author; I think it makes sense to keep it to a simple list of class
> names, as the most basic, generic way to distinguish "types" of
> fieldsets. I think pretty much any use case can be handled via this
> mechanism, since you can write custom template tags if needed to
> provide reusable display logic. (I'd be open to the "attrs" option,
> but am quite opposed to "template": form definitions seem like
> entirely the wrong place to embed template names.)
Here I would prefer to be minimalistic. For example, widgets have
"attrs", not "classes", so it is more consistent to use "attrs". And I
have proposed "attrs" in another proposal because I think that there
is general problem - how to customize parts of form rendering without
writing of whole templates? So I would start with items "fields" and
"legend", other items could be added later.
> I would of course assume that a patch for fieldsets in forms would
> also involve porting the admin's fieldsets to use this feature.
It is not so simple. Our proposals are that "fields" are list of field
names. But in admin "fields" are list of items - and each item can be
field name or list of field names. So I think that generally it is not
possible to port admin's fieldsets to these proposals' fieldsets -
proposals' fieldsets are subset of admin's fieldsets. (And syntax from
admin seems to be too complex for Django core.)
I will try to implement the opposite approach I have proposed in
previous mail - extract fieldsets meta attribute of form to fieldset
attribute of model admin.
> FWIW, I think it would be much preferable to separate discussion of
> orthogonal features into separate threads, even if they are all form-
> related. Makes it much easier to follow the discussion.
>
> Thanks!
>
> Carl
>
> [1]http://bitbucket.org/carljm/django-form-utils
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-develop...@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
