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.
>
> > 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.
