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 <[email protected]> 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 [email protected]. > To post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
