[please excuse the slight chop-up-and-reordering of your
original into my quoting]
On 07/11/2010 10:36 AM, Russell Keith-Magee wrote:
{% form myform %}
For what my vote may be worth, I'm -0 on this...
{% form myform field birthdate using calendar %}
and -1 on this
{% form myform field birthdate using calendar important %}
{% form myform field name using autocomplete:"name_autocomplete" %}
and REALLY -1.0e1 on this syntax-soup. Does this result in
something that looks like the following monstrosity?
{% form myform field name using
autocomplete:"name_autocomplete" field birthdate using calendar
field other_field using some_other_chrome_or_widget%}
Putting in a subtle plug for one of my wish-list items, I've
always been curious why form-rendering wasn't implemented as
a filter:
{{ myform|as_ul }}
These layout schemes can be overridden and customized if you
know what you're doing, but it's not easy to do so.
I've occasionally wished for an as_dl (which would render
labels as <dt> and controls as <dd> elements), and having a
base/ancestor as_* filter object to base it off of would
make this a lot easier. This would take care of your
issue#1 (more easily extensible renderings).
Under such a scheme, I'd imagine your above examples might
look something like
{{ myform|as_ul }}
{{ myform|use_widget:"birthdate=calendar"|as_ul }}
where the use_widget (deep?)copies the input form object,
adjusting its field-widgets per the requested use_widget
modifiers. It could even be neatly stacked something like
(line-broken for clarity)
{{ myform
|use_widget:"birthdate=calendar"
|use_widget:"name=name_autocomplete"
|use_widget:"other_field=some_other_chrome_or_widget"
|as_ul
}}
For backwards compatibility, the implementations of
Form.as_*() should be able to just look something like
def as_table(self, ...):
return filters.as_table(self, ...)
I'd suspect this could take care of your issue#2.
However that leaves me with no good answer to
1) your "parameters to chrome" wish (though that might be
possibly incorporated in the use_widget parameters). I'm
not entirely clear on your chrome ideas, but I like some of
what I read in your novella. :)
2) your "put all JS at the bottom of the page" wish
3) your issue#3 about DOCTYPES, but unless filters were given
access to a rendering context in which some global
DOCTYPE-preference was specified, I haven't liked any of
the solutions I've seen bandied about on this matter
(including a settings.py directive, since I can easily
imagine a single site producing a mix of html4, xhtml
and/or html5).
However I think all 3 of my outliers are somewhat
orthogonal to the rejiggering of form rendering.
- Propagating the 'doctype' kwarg through the existing
form/field/widget infrastructure
I'm +1 on this (or something like it such as request-context
or some other bag-of-attributes that could be useful in
rendering a widget) so that widgets can tweak their
display behavior.
Just my late-afternoon rambling thoughts...
-tkc
--
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.
