Regarding the DOCTYPE problem, I don't think it's appropriate to set
the DOCTYPE as a setting for an entire project. As many have pointed
out, each bundled app could define a different DOCTYPE in their base
templates.
It doesn't make sense to apply a DOCTYPE setting to the context of a
form either, as the DOCTYPE is not set at the form level but the page
level, and all template tags that render HTML (not only forms) should
render markup that is appropriate for the DOCTYPE in use.
What about adding a {% doctype %} template tag for use in base
templates which will not only render the appropriate DOCTYPE, but
store it in the context? Then templates that extend from the base
template will have access to this context variable and know whether or
not to include a trailing forward slash for self closing elements, or
whether or not `email` fields should be rendered as `text` or `email`
type?
Regarding the application of settings and substitution of widgets
inside templates, I'd like to see an easy way for designers to create
bundles of presentational logic (templates, stylesheets, images) which
they can pass in or refer to as arguments to {% form %} or {%
formfield %} template tags. This could take the form of {% form myform
myformpresentationbundle %} or {% formblock %}{% formbundle
myformpresentationbundle %}{% fieldbundle mydatefield mycalendarbundle
%}{{ myform }}{% endformblock %} or {% formfield myform.mydatefield
mycalendarbundle %}.
I'm not sure how these bundles would be defined or made available to
and loaded from the templates. I don't think having to create template
tags and load them (especially if they override built ins) is going to
be user friendly for designers. Perhaps the {% form %} and {%
formfield %} template tags could just be inclusion template tags, but
instead of having the template that they include defined with the
template tag, they load it from the templates folder (or another
folder) according to the arguments?
Cheers.
Tai.
On Jul 12, 12:31 pm, André Eriksson <ean...@gmail.com> wrote:
> 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.
