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.
