On Thu, Nov 18, 2010 at 11:04 PM, Luke Plant <l.plant...@cantab.net> wrote:
> On Wed, 2010-11-10 at 11:34 +0100, Jannis Leidel wrote:
>
>> Not really, I'm -1 on this and gave a different proposal that doesn't
>> get rid of an existing paradigm and would solve the issues for me
>> (+0).
>
> OK, there was no further progress after that, and it would be nice to
> find some way to move along.
Completely agreed. Syntax notwithstanding, the feature is a good idea.
> It's not really fair to say that the
> proposal gets rid of an existing paradigm as if that's a negative thing.
> If you consider this as a case of defining key/value pairs, the url tag
> already does it the proposed way, so we have two paradigms, and it is
> better to choose one going forward (as we did with things like whether
> backend settings should specify the module or the class).
>
> For the people who have worked on this, I think it would be shame for
> this feature to get stuck at this point. Our contributing guidelines
> say:
>
> Since this process allows any core committer to veto a proposal, any
> "-1" votes (or BDFL vetos) should be accompanied by an explanation that
> explains what it would take to convert that "-1" into at least a "+0".
>
> From what I can tell, it appears that the answer would be "use the 'as'
> syntax instead of the '=' syntax". To me, it doesn't seem fair to use a
> -1 vote in this way, since the choice of syntax is definitely a
> subjective matter and:
>
> 1) there is precedent for the proposed syntax in the Django template
> system.
>
> 2) all the other people who have weighed in, including 3 core devs,
> actually prefer the proposed syntax.
I should point out that my support is a +0, not +1. If we were
starting with a clean slate, I prefer the terse syntax, but blocktrans
sets a compelling precedent to go the other way.
However, given the Unless Jannis is willing to downgrade his -1 to a
-0, I think a BDFL judgement is called for here.
I believe Jacob is travelling at the moment; so if anyone sees him,
poke him and point him in the general direction of this thread.
To summarize, the options on the table are:
OPTION 1:
{% include "foo.html" with a as foo and b as bar %}
{% with a as foo and b as bar %}
Pros:
* Consistent with existing 1-clause {% with %} tag, and the syntax of
{% blocktrans %}
* Establishes an overall design where "as" is used to set variables
(both in current context and internal to blocks).
Cons:
* Verbose. Lots of placeholder keywords required.
OPTION 2:
{% include "foo.html" with a=foo b=bar %}
{% with a=foo b=bar %}
Pros:
* Terse
* Consistent with syntax for the {% url %} tag
* Allows us to establish an overall design where the "as" keyword is
used to set something in the current context; tags that set variables
that only apply in that template block use assignment (However, this
doesn't work retrospectively for {% with a as foo %} or {% blocktrans
%}).
Cons:
* Inconsistent with existing {% with %} implementation; would
require a compatibility option for the single variable case of with,
and for blocktrans.
* Could be considered to be too "programmery".
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.
