Russ, Thanks for your help. I ultimately abandoned the (over-engineered) nested idea. Since we were on a tight deadline, I decided to focus only on the one page I needed customized. The template has three sections—header, body, footer. I use select_template to find the right templates to include in these sections.
The code is at https://github.com/edx/credentials/pull/210 and https://github.com/edx/credentials-themes. Ultimately, I think I want to migrate to something similar to https://github.com/moorinteractive/wagtail-themes/. While it uses thread locals (of which I am not a fan), it ultimately allows for the entire site to be themed without having to customize every view/template. Thanks again, Clinton Blackburn On Saturday, April 8, 2017 at 11:27:19 AM UTC-4, Russell Keith-Magee wrote: > > Hi Clinton, > > On Sat, Apr 8, 2017 at 4:05 PM, Clinton Blackburn <clinton....@gmail.com > <javascript:>> wrote: > >> Russ, >> >> How would this work for base/nested templates? Say my view is rendering >> the potential templates ['my-theme/page.html', 'page.html'], and the >> templates inherits base.html. Do I have to override base.html for every >> theme if I want base.html (or any other child/parent template) to be >> theme-able? Is there a version of {%include%} that takes an array, or will >> I need to write my own tag? >> > > The template loading list (i.e., [‘my-theme/page.html’, > ‘page.html’]) indicates which template will be rendered. Each of those > template can, themselves, include or extend any other template they want. > So, ‘my-theme/page.html’ could extend ‘page.html’, which could, in turn, > extend ‘base.html’ - or both templates could directly extend ‘base.html’. > > The argument that is passed to {% extends %} is also something that can be > paramterized - so, for example, you can pass in a variable as template > context that contains the “parent” template - so you could do something > like having “page.html” that starts “{% extends theme %}”, and then pass in > {“theme”: “path/to/theme.html”} as context. > > The same applies to {% include %} - anywhere that you pass in a string in > a template could, potentially, be a variable. > > The approach that will work best depends on exactly what “theming” means > in your context. > > Is it the same basic structure that just has a different style sheet? Then > having a template with {% include theme %} will probably be best. > > Or is it a base structure where key bits of content are different? In that > case, having a my-theme/page.html that extends page.html, and using the > template loader trick will probably be best. > > Or are the same *pieces* on each page, but laid out differently for each > user? In that case, you probably want a page.html that starts with {% > extends theme %}, so that the theme establishes basic page structure, and > the page defines the blocks that are placed into that structure. > > Yours, > Russ Magee %-) > > -- You received this message because you are subscribed to the Google Groups "Django users" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscr...@googlegroups.com. To post to this group, send email to django-users@googlegroups.com. Visit this group at https://groups.google.com/group/django-users. To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/c87a83a3-da45-43c9-bf07-5b318975364e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
