On Jul 12, 5:27 am, Javier Guerra Giraldez <jav...@guerrag.com> wrote:
> > 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 %}
>
> personally, i don't think this is a nice solution. {%include%}'ing a
> set of settings is not a default, it's a packaged setting.
My idea was merely to provide a very flexible way for template authors
to define a single point of form settings if they so choose, without
introducing yet another way of defining settings and figuring out a
way to make it flexible enough to handle the various use cases. As
Russ pointed out, sometimes doctypes aren't sitewide, whereas other
times they are. By allowing (but not requiring!) the inherent
flexibility of django's template system in the form settings, the
template authors and by extension the designers are put in control of
how forms are rendered and to what extent default settings should be
provided and to what magnitude they affect the site.
André
--
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.
