On 3 November 2010 10:03, Jannis Leidel <jan...@leidel.info> wrote:
> On 27.10.2010, at 09:46, SmileyChris wrote:
>
>> On Oct 27, 5:35 am, Łukasz Rekucki <lreku...@gmail.com> wrote:
>>> I would like to bring this up again, because this is something that
>>> would really improve readability of my templates. I'm mainly
>>> interested in ticket #7817 (the include tag changes), but extending
>>> "with" tag (ticket 9456) would keep things consistent.
>>
>> Here's a link to the ticket for the lazier ones among us:
>> http://code.djangoproject.com/ticket/7817
>>
>> The main decision which needs to be made is one of syntax.
>>
>> The current proposal uses:
>> {% include "name_snippet.html" with name="Joe" greeting="Hello" %}
>> but this introduces an inconsistency with the {% with %} tag.
>
> I'm feeling strongly against moving from the "value as name" to the
> "name=value" notation, since I think the former is actually more readable
> than the latter for the targetted audience (template authors).
>
>> Consistency would be nice, but I think this starts to look a bit
>> confusing, static tokens outnumbering actual functional ones:
>> {% include "name_snippet.html" with name as "Joe" and greeting as
>> "Hello" %}
>
> Well, I think that's actually not a bad notation at all (if using the correct
> order :), so for #7817 I propose the following syntax (as analogously
> proposed by #9456 for {% with %}):
>
> {% include "name_snippet.html" with "Joe" as name and "Hello" as greeting %}
My argument against this is that it's not consistent use of "as". Take
the {% url %} tag:
{% url my_view object_id=5 section="B" as my_view_url %}
There is clear separation about what is an argument to the tag and
what is being set in current scope. Now {% with %} and {% blocktrans
%} behave the same with a small difference of changing current scope.
{% with "John" as person_name %}
{# context was changed by using "as" and person_name is now availble #}
{% endwith %}
Thus I would leave {% with %} and {% blocktrans %} with this syntax as
it's intuitive and readable. The proposed change to {% include %} is a
bit diffrent. Currently, there is a way to write inclusion tags and
pass arguments to them, that usually land in the context. So my custom
inclusion tag right now will look like this:
{% show_note note "Title" %}
If we were to extend the inclusion tag shortcut to support keyword
arguments I think most people would expect it to look like this:
{% show_note note=object title="Title" %}
rather than:
{% show_note object as note and "Title" as title %}
because that's how most tags get their arguments passed. {% include %}
with proposed extensions can be considered as a inclusion_tag with a
variable template name:
{% include "foo.html" x=1 y=2 %}
It takes arguments and doesn't modify scope, so It should be
consistent with tags that do the same. The interleaving "with" keyword
could be removed not to confuse people.
--
Łukasz Rekucki
--
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.
