I'd suggest to change both include and with/blocktrans syntax into
more programmer-friendly style:
{% include "part.html" title=obj.title|capfirst main_class="large" %}
This is both more dense, and from quick grasp you can see where are
the delimiters ("as" is not so good for this).
Also I think we need an argument to tell that outer context is passed inside.
On Tue, Jun 8, 2010 at 11:30 PM, Gonzalo Saavedra
<gonzalosaave...@gmail.com> wrote:
> I'm +1 on the optional "with" parameter for {% include %}. -1 on
> adding a new tag for this.
>
> I also use {% with %}{% include %} a lot in templates but we should
> follow with/blocktrans syntax for consistency:
>
> {% include "part.html" with obj.title|capfirst as title and "large"
> as main_class %}
>
>
> A related proposal for the "with" tag: It'd be nice to support more
> than one variable definition (as blocktrans does):
>
> {% with "a" as var1 and "b" as var2 %}...{% endwith %}
>
> The current solution is nesting "with" tags, which is not very pretty.
>
>
> gonz.
>
>
> 2010/6/8 Marco Louro <mlo...@gmail.com>:
>> Gabriel,
>>
>> I only made that decision because I didn't see the need to have whole
>> context, and the only time I have needed it was because of the {%
>> csrf_token %}. This is just my use-case, but I understand that other
>> people might want to use it differently. I don't think it makes much
>> of a difference, a clean context may avoid some collisions from time
>> to time, but it may have bigger drawbacks for other people.
>>
>> Hi Jeliuc,
>>
>> No, I don't.
>>
>> On Jun 7, 7:59 pm, Gabriel Hurley <gab...@gmail.com> wrote:
>>> Extending the include tag seems like a fantastic idea! I end up
>>> writing the {% with %}{% include %} combo all the time for my reusable
>>> template snippets.
>>>
>>> However, I feel like selectively clearing the context inside a
>>> template tag is asking for trouble and/or confusion. It also sounds
>>> like it goes against Django's "templates require no knowledge of
>>> programming" principle. While I can see how you might run into context
>>> name collisions in a *very* large or complicated project, the right
>>> solution there seems like it ought to be to clean up your context and/
>>> or templates outside of the template itself... Even in projects with
>>> dozens of installed apps (both my own and third-party ones mixed
>>> together) I've never had that problem where two minutes of tweaking
>>> couldn't fix it for good.
>>>
>>> I'm certainly not saying you don't have a use case for it, or that it
>>> wouldn't be extremely helpful to you. Just that having a tag that
>>> clears the context sounds fishy to me...
>>>
>>> All the best,
>>>
>>> - Gabriel
>>>
>>> On Jun 7, 10:52 am, Marco Louro <mlo...@gmail.com> wrote:
>>>
>>>
>>>
>>> > I'd prefer extending the {% include %} tag actually, but didn't of
>>> > that in the first place.
> [...]
>
> --
> 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.
>
>
--
Best regards, Yuri V. Baburov, ICQ# 99934676, Skype: yuri.baburov,
MSN: bu...@live.com
--
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.
