Jacob Kaplan-Moss skrev 2013-04-17 18:36:
On Wed, Apr 17, 2013 at 10:50 AM, Emil Stenström <e...@kth.se> wrote:
{% extends "base.html" %}
{% block content %}
<div class="warning">Be careful when changing these settings!</div>
{% block content %}{% endblock %}
{% endblock %}
I find this intensely confusing -- I can't build a mental model of
what's going to be rendered there. Allowing re-definining of existing
blocks nested inside those blocks... ouch. I'm -1 on allowing this; it
just seems incredibly confusing and error prone.
The mental model I have, and that I've seen many beginners have when
comming from other languages, is that the outmost tag is what you're
"filling in", and the innermost block is what you're making available
for child templates.
ASP.Net:
Parent: <asp:contentplaceholder id="Main" runat="server" />
Child: <asp:content ContentPlaceHolderID="Main" Runat="server"> ...
</asp:content>
JSF:
Parent: <ui:insert name="content" />
Child: <ui:define name="content"> ... </ui:define>
Rails:
Parent: <%= yield :head %>
Child: <% content_for :head do %> ... <% end %>
I'm not saying I think you should differetiate the two, just explaining
my mental model. The big difference is of course that I'm separating
what a template consumes and what it makes a block available to child
templates.
I understand the differences to your mental model, that nested blocks
are also available to child templates.
The general way I've solved this in the past is pretty straightforward::
{% block content-wrapper %}
<div class="warning">Be careful when changing these settings!</div>
{% block content %}{% endblock %}
{% endblock %}
What's wrong with this?
This is "Alternative 1" in my original message, sorry if this was
unclear. Say I change base.html to have a content-wrapper block, and put
your code in base_with_warning. Half my templates inherit from base and
half from base_with_warning. Now when I decide I want to add a warning
to a template that previously didn't have one, I change parent template
AND need to remember to rename the block to content instead of
content-wrapper. The "rename block"-part is the difference between our
two variants.
In projects with lots of templates, this quickly becomes a maintainance
nightmare. People forget the change the block name, and accidentially
don't get the warning they expect, even though they are explicitly
inheriting from base_with_warning. It's a mess.
This is the problem I'm trying to solve with my proposal. I agree it's
slightly backwards, but I couldn't come up with a smarter way.
/Emil
--
You received this message because you are subscribed to the Google Groups "Django
developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at http://groups.google.com/group/django-developers?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
