Good proposal overall. One thought I have in order to try and combat
the massive parameter list of {% form %} is to optionally add an
ending tag, as well as sub-tags:
{% form myform %}
{% using birthday=calendar %}
{% renderer "as_ul" %}
{% autocomplete "name_autocomplete" %}
{% doctype xhtml1 %}
{% endform %}
I see this as having several advantages:
1) It introduces a clearer way of laying out settings.
2) It leverages the template engine for specifying defaults in a
simple but ingenious way:
{% form myform %}
{% include "form_settings.django" %}
{% endform %}
-- form_settings.django:
{% doctype xhtml1 %}
{% replace_widget datetime=calendar %}
And because of the flexibility of the template engine we can easily
specify either section-, site- or project-specific form settings, with
the use of block tags and overriding them. This can be accomplished in
a few ways:
1) Keeping the current {{ myform }} method for displaying forms
without settings attached.
2) Converting to always using {% form myform %}, where the {% form %}
tag parses until it either finds a matching {% endform %} tag or a new
{% form %} tag; a new {% form %} tag means that there are no settings
attached.
3) Adding a parameter to {% form %} for settings: {% form myform
detailed %} {# settings #} {% endform %}
4) Adding two template tags, one for simple form rendering, another
for detailed form rendering. Naming them is left as an exercise to the
reader.
--
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.
