On Sep 26, 6:34 pm, Rob Hudson <treborhud...@gmail.com> wrote:
> This is the bit I was hoping we could get to. What would that
> refactoring look like, you think? Would it involve making forms use
> Templates? Or something else?
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.
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.
> We've got django.forms and tags/filters on the plate. How might we
> fix something like comments which has templates which write out XHTML
> (or other little places which hand code HTML)?
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 />
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).
> For example, I think the Django admin is fine as XHTML since it isn't
> intended to be an included part of your website. But say we were able
> to easily set a different doctype that rendered as HTML4. Does that
> have the possibility of really breaking things?
The JavaScript differences only come up when you start serving stuff
as application/xml+xhtml, which I would strongly suggest we avoid
doing at all costs (hence the need to stick the admin with XHTML 1.0
and avoid ever upgrading to 1.1). I'm not worried about that aspect.
Cheers,
Simon
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
