Also +1 from me for extending the include tag instead of having a new one.
Bye default it should keep its behaviour and use the current context
for the included template. Marco's use of a new, clean context
(demonstrated with the snippet below) is also possible to support.
{% if label %}
<label>{{ label }}</label>
{% else %}
You can just pass in an empty string, like one of the following three examples:
{% include "part.html" with label= title=obj.title %}
{% include "part.html" with label="" title=obj.title %}
{% include "part.html" with "" as label and obj.title as title %}
(I don't want to propose the implementation of all three syntaxes. I
just want to demonstrate that all possible syntaxes can handle Marco's
usecase.)
--
Servus,
Gregor Müllegger
2010/6/8 burc...@gmail.com <burc...@gmail.com>:
> 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.
>
>
--
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.
