On Sat, Sep 26, 2009 at 11:33 AM, Simon Willison
<si...@simonwillison.net> wrote:
> I don't think it would involve form widgets being rendered with
> templates simply because of the performance overhead - even with the
> template caching improvements it's still a lot of work just to output
> an input tag. It might involve some kind of light-weight helper for
> outputting tags though - render_tag('input', {'type': 'text', 'name':
> 'blah'}, xhtml=True) maybe.
For lack of knowing about anything better, I keep falling back to
Werkzeug's HTMLBuilder class[1]. Pulled out and stripped of comments,
it weighs in at 77 lines of code...
Here's a brief Python shell of how it works...
>>> html = HTMLBuilder('html')
>>> html.input(type='text', name='blah', value='"Quote & Ampersand"')
u'<input type="text" name="blah" value=""Quote & Ampersand"">'
>>> html.select(name='template', id='id_template', *[html.option(v, value=k)
>>> for k, v in dict({1: 'One', 2: 'Two', 3: 'Three'}).iteritems()])
u'<select id="id_template" name="template"><option
value="1">One</option><option value="2">Two</option><option
value="3">Three</option></select>'
I really like how it handles children nicely, as in the select/option
example above.
>>> xhtml = HTMLBuilder('xhtml') # XHTML dialect
>>> xhtml.input(type='text', name='blah', value='"Quote & Ampersand"')
u'<input type="text" name="blah" value=""Quote & Ampersand"" />'
This automatic CDATA escaping in XHTML is also nice:
>>> html.script('var id=document.getElementById("id")')
u'<script>var id=document.getElementById("id")</script>'
>>> xhtml.script('var id=document.getElementById("id")')
u'<script>/*<![CDATA[*/var id=document.getElementById("id")/*]]>*/</script>'
I could see using something like this and making a template tag
wrapper around it like the namespace template tag you mention below.
I *think* that would simplify a lot of what you see in the Django
template widget render code that deals with attributes (e.g.
buildattrs, flattatt), which should make writing widgets and
sublcassing widgets a bit easier.
> The form.as_p stuff works as either HTML or XHTML. It would be nice to
> further emphasise the ease with which people can create their own
> reusable form templates (define them as an includable fragment that
> iterates over the form), and it would be nice if there were more
> finely grained methods for things like accessing the HTML ID of a form
> field. I don't see any reason to templatise those parts in particular
> though - unless someone has smart ideas about how baked in default
> templates could dramatically improve the overall form experience.
I agree with what I think I'm reading here -- a goal being to give
designers more fine grained control over the form and form elements at
the template level.
> That's tricky. There are really only a few tags that actually differ -
> anything that needs to be self closing, which means the following:
>
> <area />
> <base />
> <basefont />
> <br />
> <hr />
> <input />
> <img />
> <link />
> <meta />
Also:
<col />
<frame />
<param />
> Of these, only meta, link, img, input and br are really common. I can
> think of a few ways of dealing with this, none of them particularly
> enticing:
>
> 1. a {% selfclose %} template tag:
>
> <br{% selfclose %}>
>
> {% selfclose %} outputs either blank or " /" depending on the doctype.
>
> 2. a {% tag %} tag:
>
> {% tag br %}
>
> Like the {% field %} tag, this could take optional attributes:
>
> {% tag br class="break" %}
>
> 3. {% field %} style tags for all of the self-closing XHTML tags:
>
> {% br %} {% br class="break" %}
> {% hr %}
> {% meta name="dc:author" value="Simon" %}
>
> This option really sucks - that's 9 new template tags polluting our
> default template namespace which do almost nothing. That said, if we
> added template tag namespacing we could at least do {% tag.br %}, {%
> tag.hr %} etc.
>
> They're all pretty horrible, but I think out of those I prefer option
> 1 (maybe with a better, shorter name).
I think you might want both 1 and 3. (1) for those that want finer
control or just don't want to use the underlying HTML wrapper, and (3)
for those that do.
Would it be something to consider adding special case tag, like
comments, to represent the self closing slash depending on current
context's doctype? For example, something like {% / %}?
[1] http://dev.pocoo.org/projects/werkzeug/browser/werkzeug/utils.py#L126
I feel like I'm starting to get a picture in mind for all the pieces
at play here.
Thanks,
Rob
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@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
-~----------~----~----~----~------~----~------~--~---
