On Mon, Jul 12, 2010 at 10:31 AM, 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 %}
As I commented to Tim; the {% form X field ... %} tag isn't trying to
render the entire form -- it's just rendering a single field. This
removes the need for "using" and "autocomplete" as a subtag. The only
way a full field is rendered is in the simple case of {% form X %},
which is the equivalent of the current {{ form }} -- i.e., just render
the entire form using defaults (where "default" == doctype, layout and
chrome).
Secondly, the "renderer" subtag misses the significance of the trick
with the template tag loading. The aim of the loading trick is that {%
form %} *is* an as_ul renderer; it doesn't need to be specified
separately.
Lastly, the doctype subtag isn't something that should be specified on
a per-form basis. It's a per-document attribute. My proposal gets
around this by tying the doctype to the form tag itself, which is a
constant through the rendered page.
> I see this as having several advantages:
>
> 1) It introduces a clearer way of laying out settings.
For some definitions of clever. It also has some potential problems:
* How do you put a <hr/> between the name and birthday fields?
* How do you render fields in a different order to the form specified
on the form?
* How do we handle content that is included inside the {% form %} block?
> 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 %}
Again, most of these default don't actually need to be specified if
you treat the {% form %} tag as encompassing the doctype and renderer
requirement. Arguing that template inclusions are a convenient way to
get around the fact that defining a form requires lots of subtags
doesn't seem like a net win to me.
Call me -0 on this; Given that there's only one tag that actually
needs to be a subtag (using), I don't see what making {% form %} a
full block tag gains us.
Yours,
Russ Magee %-)
--
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.
