Something related, that we could really use is passing not just
variables to the include, but also blocks. I tried to implement a
template tag for this, but it doesn't work together with how Django
replaces blocks in the extended template at compile time instead of
during the renderering.
I would like to do:
## in the main template:
...
{% include "decorator.html" %}
{% block "content" %}
...
{% endblock %}
{% endinclude %}
...
## In decorator.html
<div class="...">
{% block content %}{% endblock %}
</div>
##
So, the main templates includes decorator.html, but replaces the inner
block "content", by the block it passes to the include.
The decorator pattern, wraps the input in some nodes.
There are use cases where this is required to keep the templates DRY.
I think only a few templating languages are able to do this.
The .NET framework supports the design pattern pretty well, as far as
I remember.
The alternative in this particular example is to use two include tags
"before.html" and "after.html", but is ugly because the opening and
closing html tag are separated over different files.
-- Jonathan
On 8 juin, 19:47, Gregor Müllegger <gre...@muellegger.de> wrote:
> 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
> >> athttp://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
> > athttp://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.
