After I read that I created the doctype part in a patch on this ticket
but didn't have the genius idea of the {% field %} tag to take it the
rest of the way...
http://code.djangoproject.com/ticket/7281
So awesome and simple. I love it.
I'll get rid of my weird form hack on my latest project and test this out soon.
Thanks,
Rob
To me it looks a bit weird but I'm afraid my English is not apt to dare
to describe it :-). May be this will look cleaner:
{% doctype "xhtml1" "<!DOCTYPE my-custom-xhtml-doctype>" %}
E.g. instead of "doctype(mode, silent=False)" it's "doctype(mode,
override='')"
There's also xhtml-mp, wml and chtml for mobile apps...
> The current design of the {% doctype %} tag supports setting your own
> custom doctype using the "silent" argument. You need to pick a
> supported doctype that is closest to your own, then supress output
> with "silent" and add your own instead:
...which can always be handled by this mechanism if not directly
supported.
--
Sean L
As a 3rd party app this is awesome. It's simple and clean and doesn't
require much from the user.
But as part of Django itself, it seems like fixing django.forms (the
source) would be a better solution.
To avoid adding yet another setting (unless it's warranted here) can
the setting of a doctype in a template tag set a value in
django.conf.settings that django.forms can then check (with a
reasonable default)?
I recall seeing a patch that adds a new setting and updates (at the
time) django.newforms with some if/else logic based on the setting to
the various widgets' render methods. I can't seem to find it now.
I'm just trying to point out that for Django to output a string that
then later gets "fixed" smells funny to me (ask Malcolm likes to say).
-Rob
Why not just adopt {% field %} as a default way for rendering fields
instead of unicode()ing a them? As far as I recall Simon had already
proposed this some time ago.
This isn't forms specific, but I have various classes that output HTML
into templates and one pattern I've used is to take the context in
their render() method, then display the variable with a tag that calls
render(), like:
{% render my_variable %}
I think it'd be interesting to apply this pattern to general variable
lookups, as it would solve this issue, plus be applicable to many more
problems. Variable lookups could check for render() and call it if
it's there, passing the context. Then you just call {{ my_variable }},
or {{ field }}.
Too big of a change?
-Justin