On Mon, Jul 12, 2010 at 1:35 AM, Javier Guerra Giraldez
<jav...@guerrag.com> wrote:
> On Sun, Jul 11, 2010 at 12:16 PM, David Larlet <lar...@gmail.com> wrote:
>> Le 11 juil. 2010 à 17:36, Russell Keith-Magee a écrit :
>>> {% load xhtml_p_forms %}
>>> {% form myform %}
>>
>> Just a personal feedback, to me the rendering strategy is related to a whole
>> project and should be defined in settings, it's too easy to forget a loading
>> in a template. I know that you can use the django.template.add_to_builtins
>> function but it in this case it should be documented.
>
> i'd say the other way around; it's not hard to imagine a single page
> with two or three forms rendered with different styles: a 'main' one
> rendered as_table(), and a footer field rendered as_p().
I agree - form rendering scheme isn't something that is site-wide, and
it isn't necessarily page-wide either. I acknowledge that page-wide
rendering is a limitation of my proposal. If we can find an elegant
way to represent it, I agree that it is worth considering.
> in that
> case, {%load%}'ing the style is too coarse granularity. i'd prefer an
> optional parameter to {%form%} to choose the renderer.
>
> something like:
>
> class myformrenderer (forms.as_table):
> name = 'left_table'
> ......
>
> and in the template you could say {% form myform:"left_table" %}
I can see where you're going with this; I have two concerns:
* Duplication. The 'left_table' flag needs to be applied to every use
of the {% form %} tag on a page. If you're
manually rolling out every field on a form, this is a lot of code duplication.
* Composibility. If I understand your intention, a form library would
need to provide all the layout schemes that you want to have available
on a page. That means if you wanted "P" and "UL" forms on the same
page, you would need to define a combined "P & UL" form library. This
sort of composition doesn't strike me as a desirable goal.
One proposal that has been made elsewhere in this thread (by Iván
Raskovsky) is to introduce namespacing for tempatetags. This has been
mooted several times in the past, and there have been several proposed
syntaxes; here's yet another:
{% load xhtml_div_forms %} -- loads into the root namespace
{% load namespace foo xhtml_p_forms %} -- loads forms into the 'foo' namespace
{% load namespace bar xhtml_ul_forms otherlib %} -- loads forms and
otherlib into the bar namespace
{% bar:form firstform %} -- renders as ul
{% foo:form secondform %} -- renders as p
{% form thirdform %} -- renders as div
This way, you can have two different implementations of {% form %} on
the same page if you need them. Whatever the final agreed syntax, this
isn't a form-specific feature; it could be useful anywhere that you
need to disambiguate template tags/filters. This means the discussion
is orthogonal to this forms discussion; if we agree that namespacing
is a way to tackle this general problem, we can keep the discussion
about how to implement namespaces as a separate issue.
>> Again, why not directly in settings in order to be project's specific? Is
>> there anybody mixing doctypes on the same website? (backward compatibility
>> maybe?)
>
> here i fully agree, doctype should be project-specific.
As noted elsewhere, there's no guarantee that doctype will be
consistent across an entire project.
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.
