Hi Emil,
On 04/17/2013 09:50 AM, Emil Stenström wrote:
> Proposal:
> Make it possible to use the same template block name twice, if the
> second one is nested within the first one. Inheriting from the template
> fills in the innermost block.
This is an interesting proposal, but I am concerned that the syntax you
propose is confusing on several levels:
1) If I haven't seen this done before, and I'm reading your template and
I see the two nested blocks, it's not at all intuitively obvious that
child templates would override the inner one rather than the outer one.
In fact, my naive assumption would have been the opposite.
2) If the "warning" HTML in your example is lengthy, I may see the outer
block and not immediately notice the inner one, and be confused as to
why the child templates aren't overriding the "content" block I can see
right in front of me.
I also think you missed the best (existing) solution to your example
problem:
> ----------------------
> Background (why is this useful?):
> Say you have one base.html template defining a {% block content %}, and
> ten templates inheriting from it and defining the contents of the block.
> Now you decide that five of those templates actually should have a
> warning message at the top, and you decide to make a new
> base_with_warning.html template. You should should now be able to just
> change what block five of the templates inherit from, add the warning to
> your new base template, and be done with it?
>
> Not really. Your base_with_warning.html would have to look like this:
>
> {% extends "base.html" %}
> {% block content %}
> <div class="warning">Be careful when changing these settings!</div>
> {% block content %}{% endblock %}
> {% endblock %}
>
> And this doesn't work in Django because duplicate block names are not
> allowed. I think making this possible would make cases like the one I'm
> describing above much easier to handle.
>
> ----------------------
> Alternatives (this is how you should solve it instead...):
> There are other ways to solve the problem I'm describing above. Let me
> list a few and talk about the problems I see with them:
>
> 1) Create a new template block in base_with_warning.html and change the
> five templates to use that block instead.
>
> Problem: This puts the burden on developers to remember all kinds of
> content blocks they have in this project, and change them depending on
> what template they happen to be inherit from. The interface to the
> developer working on a new child template is much cleaner if they know
> they can always use the content block, and that the template they
> inherit from with handle the rest.
Why not instead add a new block to base.html? So you'd change base.html
to have:
{% block outer-content %}
{% block content %}{% endblock content %}
{% endblock outer-content %}
And base_with_warning.html:
{% extends "base.html" %}
{% block outer-content %}
<div class="warning">...</div>
{% block content %}{% endblock content %}
{% endblock outer-content %}
I think this achieves your goal that none of the inheriting templates
have to change anything besides which template they extend. And it does
it with very little added verbosity in the base templates, a clearer
conceptual layering of blocks, and less potential for confusion when
reading the templates.
> 2) Make a child templates call super, and put the warning div inside the
> content block in base_with_warning.html.
>
> Problem: It's very easy to forget calling super when making a new
> template. It quickly becomes repetitive to type block.super in each of
> the templates. Should I call super in the five templates without a
> warning too? Just to be sure it isn't forgotten if someone changes the
> inherited template.
>
> 3) Use an include tag in each of the child templates instead of inheriting.
>
> Problem: This is just as repetitive as copy-pasting the div to each of
> the subtemplate, it's just the {% include "warning.html" %} is a shorter
> string to copy-paste. As with all copy-paste, it makes it easy miss one
> instance when changing the others. Not maintainable.
>
> 4) Use a template variable to decide whether to render the warning or not.
>
> Problem: This moves the copy-paste to the view logic. Now I need to
> remember to pass the right variable in the view instead, with the same
> problem as with copy-paste above.
>
> 5) Write a custom template tag that does what I want.
>
> Problem: I really don't know how to do this, and I haven't found someone
> that has written a tag like that after are plenty of googling.
I agree that none of these solutions are good.
Carl
--
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.
