I've been wanting this exact feature for years. I've always struggled to
explain the problem, but I've had numerous cases where this would have made
for a vastly simpler template structure.
Big +1 from me.
On 17 April 2013 16:50, Emil Stenström <e...@kth.se> wrote:
> Hi,
>
> 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.
>
> ----------------------
> 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.
>
> 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.
>
> ----------------------
> Backwards compatibility (this will not break stuff!):
> Since duplicate block names are not allowed today, this change would be
> 100% backwards compatible. Everything would continue working as it always
> has.
>
> ----------------------
> FAQ:
> a) How would you inherit from a template with duplicate blocks with the
> same name? This proposal only deals with the case where the first block is
> defined inside the second block. If this happens the child templates
> content should fill the INNER block, not the outer one. There would be no
> way to override the outer block, since that would be shadowed by the
> redefined inner block.
>
> b) If we allow for multiple blocks with the same name, what should happen
> with two blocks side by side (not nested)? We wouldn't allow that. This
> proposal is only about duplicate blocks when nested inside eachother. All
> other duplication would still yield the same error.
>
> c) I have another suggestion that solves your problem without the problems
> with 1) - 5) above, that doesn't require a change in django? That really
> isn't a question, but fine :) Bring it on! I'm really interested in solving
> the problem described in the background section in a clean way, not a
> particular tech solution.
>
> d) Do other people have this problem? I've found a few:
> http://stackoverflow.com/questions/15448211/django-template-block-overriding/-
> http://stackoverflow.com/questions/8717521/django-multi-level-template-extends-and-nested-blocks-
> This could also be used to handle nicely breadcrumbs in multiple levels.
> You can probably think of more use-cases.
>
> e) Is this the same as Ticket #4529:
> https://code.djangoproject.com/ticket/4529 ? No. The code in that ticket
> would still not work.
>
> ----------------------
> Next steps:
> I'm very eager to hear your thoughts on this, and maybe, if you think this
> is a good idea, start to write up a ticket.
>
> ----------------------
> Thanks for reading this far! I love the work you all do on making Django
> better!
>
> --
> 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.
>
>
>
--
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.
