On Jun 24, 12:16 am, Karen Tracey <kmtra...@gmail.com> wrote:
> On Tue, Jun 23, 2009 at 11:05 PM, Steve Howell <showel...@yahoo.com> wrote:
> > > {% extends "base_form.html" %}
> > > {% with form.instance as object %}
>
> > I understand why tags outside the block would not render anything
> > within the parent but it is not as clear to me why the with statement
> > would not change the context for template code that it lexically
> > encloses. It seems like this code should either dwim or raise an
> > exception.
>
> It doesn't lexically enclose anything if it is inside a child template and
> not inside a {% block %}.
>
> Consider:
>
> parent.html:
>
> {% with something as x %}
> {% block b1 %} {{ x }} in parent b1{% endblock %}
> {% block b2 %} {{ x }} in parent b2{% endblock %}
> {% endwith %}
> {% with something_else as x %}
> {% block b3 %}{{ x }} in parent b3{% endblock %}
> {% endwith %}
>
> child.html:
>
> {% extends "parent.html" %}
> {% with something_else_again as x %}
> {% block b3 %}{{ x }} in child b3{% endblock %}
> {% block b2 %}{{ x }} in child b2{% endblock %}
> {% endwith %}
> {% with yet_even_something_else as x %}
> {% block b1 %}{{ x }} in child b1{% endblock %}
> {% endwith %}
>
> If those with/endwiths in child.html were to have some effect, what would it
> be? Where would you place them in the fully-block-substituted parent
> template? something_else_again being x encloses blocks b3 and b2 in
> child.html, yet in the parent template these blocks are found in a different
> order and have different with's enclosing them...which withs win? I just
> don't see any sensible way to make this "work".
>
> Raising some sort of error for child template content found outside of a {%
> block %} seems like a more reasonable idea. I have no idea if it's been
> asked for/considered/rejected/etc., nor how hard it would be to do. If you
> are really interested in pursuing that idea I'd first search the tracker and
> archives of this list to see if it hasn't already been discussed.
>
> Karen
Whats wrong with:
{% with something as x %}
{% block foo1 %}
{{x}}
{% endblock %}
{% block foo2 %}
{{x}}
{% endblock%}
{% block foo3 %}
{{x}}
{% endblock%}
{% block foo4 %}
{{x}}
{% endblock %}
{% block foo5 %}
{{x}}
{% endblock %}
{% endwith %}
just simply being a shortcut for:
{% block foo1 %}}
{% with something as x %}
{{x}}
{% endwith %}
{% endblock %}
{% block foo2 %}
{% with something as x %}
{{x}}
{% endwith %}
{%endblock%}
{% block foo3 %}}
{% with something as x %}
{{x}}
{% endwith %}
{%endblock%}
{% block foo4 %}}
{% with something as x %}
{{x}}
{% endwith %}
{%endblock%}
{% block foo5 %}
{% with something as x %}
{{x}}
{% endwith %}
{% endblock%}
Seem like it just makes things easier to read and maintain. If the
second example works perfectly fine, then why shouldn't the first?
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to
django-users+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
