Hi Gregor,
On 05/24/2011 09:25 AM, Gregor Müllegger wrote:
>
> Yes, defining a global default is really useful, we shouldn't skip that.
Yep, I'm definitely converted to that position ;-)
>> 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.
>
> A question for my own understanding: The difference between your
> {% formdefaults %} variant and my "modify a global scope" is just a
> syntactical difference i.e. the following examples are equal?
That's right.
> (using your syntax)
> {% formdefaults %}
> {% widget ... %}
> {% endformdefaults %}
>
> {% form %}
> {% renderform my_form %}
> {% endform %}
>
> (using the RFC syntax)
> {% widget ... %}
>
> {% form %}
> {% renderform my_form %}
> {% endform %}
>
> And you propably want to raise a TemplateSyntaxError if the {% widget ... %}
> tag is used outside a {% formdefaults %} or {% form %} enclosed block?
Also correct.
The other difference is that if we have {% formdefaults %} we can
specify the layout as an argument to {% formdefaults %} as well as an
argument to {% formconfig %} or whatever we name it (presuming we listen
to Russ on that naming, and I think he's right), and that means we
really wouldn't need {% formlayout %} as a separate tag anymore. Which I
think is a plus.
> I'm not sure yet, if it's worth the extra {% formdefaults %} tag. Ofcourse it
> prevents template authors from excidentally overriding defaults, but I think
> who will use these utilities must know about these implications anyway. It's
> somehow just reflecting the behaviour of a python module scope.
> But maybe I'm a bit too much programmer here and reflecting too much
> of my habits
> onto the template authors mind.
There are some key differences between this and Python module scope,
besides the usual "template authors aren't necessarily Python
programmers." The main one is that Python module scope is contained
within a single file; here we're talking about a global scope that
potentially extends across many template files, what with inheritance
and includes, and even into Python code files too. I think because of
this action-at-a-distance factor, there's a much greater need to make
the modification of global scope explicit, clear, and hard to do by
accident or overlook.
It also makes it easy to "grep" for places where the global defaults are
being set. Otherwise, there'd be no easy way to find them and separate
them out from scoped uses of the modifier tags.
Given that this is something you'd likely only do once in your project,
not over and over again, I think the downside of typing the extra tag is
minimal.
> After all I have no objections against the {% formdefaults %} proposal and
> would be happy implementing it if thats your prefered way.
I do think it's clearly better, though if you disagree of course you
should argue, not just do it my way ;-)
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.
