On 05/22/2011 07:22 PM, Russell Keith-Magee wrote:
> On Mon, May 23, 2011 at 6:21 AM, Carl Meyer <c...@oddbird.net> wrote:
>> Just had a quick conversation with Gregor and Chris Beaven on IRC;
>> based on a comment of Chris', we discussed the possibility of ditching
>> the {% formlayout %} tag in favor of specifying the layout as an
>> argument to the {% form %} block tag. E.g. instead of
>>
>>> {% form %}
>>> {% formlayout "table" %}
>>> {% renderform my_form %} {# will use table layout #}
>>> {% endform %}
>>
>> You'd say:
>>
>> {% form "table" %}
>> {% renderform my_form %}
>> {% endform %}
>>
>>> The description of the form tag implies that the modifier tags are able to
>>> set/modify the global state in the current template. That is something that
>>> is
>>> explicitly wanted. This way you can set a "formlayout" in the head of your
>>> base template and any other extending template will have this default for
>>> the
>>> form rendering.
>>
>> And perhaps if the layout can be specified that way, with minimal
>> boilerplate, we don't need the global-context-modifying version of
>> formlayout either.
>>
>> Not sure if Gregor was entirely convinced, but I think I'd probably
>> lean towards doing it this way.
>
> I'm not sure I am convinced. It seems to me that there would be three
> common use cases for form rendering:
>
> 1) Render this form using defaults
> 2) Render most forms using the defaults, but render for XXX using layout YYY
> 3) Render all forms on this form using YYY
>
> It seems weird to me that in order to hit use case 3, you need to wrap
> your entire template in a {% form %} block. Having a global form
> layout context so that {% formlayout %} will work without an
> encompassing {% form %} block makes more sense to me.
I guess I was comparing
{% form %}
{% renderform myform %}
{% endform %}
to
{% form "table %}
{% renderform myform %}
{% endform %}
and thinking the latter didn't seem too comparatively onerous, even if
you were doing it for every form render. But I'd forgotten that for
simple cases you could otherwise just do {% renderform myform %} with no
block tag; it is unfortunate to require the block tag every time in case 3.
For the case-by-case override, though, I'd still much rather write
{% form "table" %}
{% renderform myform %}
{% endform %}
than
{% form %}
{% formlayout "table" %}
{% renderform myform %}
{% endform %}
What if instead of allowing form modifier tags to appear unenclosed, and
making them then implicitly global, we had a {% formdefaults %} tag that
paralleled the {% form %} tag, except it defined your defaults for form
rendering:
{% formdefaults "table" %}
{% widget ... %}
{% endformdefaults %}
This is much more explicit, which means that a) a random new designer
reading your templates is more likely to notice that global defaults are
being defined, and b) you're less likely to accidentally define global
defaults because you omitted an enclosing block tag.
Global state is serious business - it means action-at-a-distance. It
should be obvious when it's happening, and hard to do accidentally.
Carl
--
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.
