On Mon, Jul 12, 2010 at 1:05 PM, Tai Lee <real.hu...@mrmachine.net> wrote:
> Regarding the DOCTYPE problem, I don't think it's appropriate to set
> the DOCTYPE as a setting for an entire project. As many have pointed
> out, each bundled app could define a different DOCTYPE in their base
> templates.
>
> It doesn't make sense to apply a DOCTYPE setting to the context of a
> form either, as the DOCTYPE is not set at the form level but the page
> level, and all template tags that render HTML (not only forms) should
> render markup that is appropriate for the DOCTYPE in use.
It's not appropriate to set doctype on a per-form basis, but that's
not really what my proposal is doing -- it's being defined on a
template tag that has scope over the template. If you import form
rendering library X, that library provides a {% form %} implementation
that specifies a doctype. Everywhere you use that instance of {% form
%}, you get the same doctype without the need to specify doctype.
> What about adding a {% doctype %} template tag for use in base
> templates which will not only render the appropriate DOCTYPE, but
> store it in the context? Then templates that extend from the base
> template will have access to this context variable and know whether or
> not to include a trailing forward slash for self closing elements, or
> whether or not `email` fields should be rendered as `text` or `email`
> type?
This has been proposed in the past [1]. I can certainly see how this
is compatible with what I've proposed.
[1] http://github.com/simonw/django-html
However, I prefer keeping things local to the templatetag rather than
relying on a template context variable. If you use the context
variable approach, writing an 'as_ul' layout requires that you provide
an implementation that can support every possible doctype, or provide
error handling when the wrong doctype is present. It also requires
handling for the 'doctype not provided' case.
Using the 'doctype defined on the tag' approach, you only have to
support the doctype that your form defines. If you want to support a
different doctype, write a different tag; if there are commonalities,
you can use a common base class. To me, this ultimately results in a
cleaner interface for end-users to implement.
> Regarding the application of settings and substitution of widgets
> inside templates, I'd like to see an easy way for designers to create
> bundles of presentational logic (templates, stylesheets, images) which
> they can pass in or refer to as arguments to {% form %} or {%
> formfield %} template tags. This could take the form of {% form myform
> myformpresentationbundle %} or {% formblock %}{% formbundle
> myformpresentationbundle %}{% fieldbundle mydatefield mycalendarbundle
> %}{{ myform }}{% endformblock %} or {% formfield myform.mydatefield
> mycalendarbundle %}.
Agreed - templates are a natural way to do this, even if only as a
prototyping tool. And bundling/packaging of these templates is
probably the biggest examples for why this might not be the best
approach.
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.
