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.
>
> The clean context implementation was to make sure we don't pass
> variables we don't want to. One of the use-cases is including form
> field "templates", so I have code like:
>
> <pre>
> <div class="row textfield {% if field.errors %}error{% endif %} {% if
> field.field.required %}required{% endif %}">
> <div class="label">
> {% if label %}
> <label>{{ label }}</label>
> {% else %}
> {{ field.label_tag }}
> {% endif %}
> </pre>
>
> if there was a "label" variable in the context but not in the
> parameters, the code above would output the wrong values. There is one
> problem with not inheriting the context: {% csrf_token %} will fail.
>
> On Jun 7, 5:35 pm, Łukasz Rekucki <lreku...@gmail.com> wrote:
>
>
>
> > On 7 June 2010 18:13, Jacob Kaplan-Moss <ja...@jacobian.org> wrote:> On
> > Mon, Jun 7, 2010 at 5:03 AM, Marco Louro <mlo...@gmail.com> wrote:
>
> > >> I'd like to propose adding a tag that includes a template with clean
> > >> context, but can accept parameters that will be added to that
> > >> context.
>
> > > Is there a reason to do this as a separate tag? Why not just::
>
> > > {% include "some/template.html" with foo=bar baz=spam %}
>
> > Personally, I would expect this to extend the current context with
> > "foo" and "bar", render the include and restore foo, bar to old values
> > (if any). Using a clean context instead is a bit non-obvious to me.
>
> > --
> > Ł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.
