I'm designing an app, and I want the "base.html" template to be a
configurable in the settings file. So a user downloads my application,
goes to the settings file, adds the setting
"BASE_TEMPLATE_NAME=somestring", and then all of my templates
automatically inherit this base template.
If I use a context processor, then every other page on their site that
uses RequestContext will get this variable as well. I tried to use a
template tag to return the base template setting, but I can't put anything
before extends.
--
Ticket URL: <https://code.djangoproject.com/ticket/21313>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_tests: => 0
* needs_docs: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/21313#comment:1>
Comment (by chrismedrela):
What's wrong about putting ``BASE_TEMPLATE_NAME`` into ``RequestContext``?
This variable doesn't seem to be secret so you don't need to hide it from
other templates.
Anyway, I'm -1 on emulating 'private' variables (variables visible only in
a specific template) using template tags.
--
Ticket URL: <https://code.djangoproject.com/ticket/21313#comment:2>
Comment (by ztorstri@…):
Replying to [comment:2 chrismedrela]:
> What's wrong about putting ``BASE_TEMPLATE_NAME`` into
``RequestContext``? This variable doesn't seem to be secret so you don't
need to hide it from other templates.
>
> Anyway, I'm -1 on emulating 'private' variables (variables visible only
in a specific template) using template tags.
It's not about being private, it's about being wasteful. There's no reason
to load the variable in templates that don't relate to the app.
I ended up writing a mixin that defines get_context and I inherit it in
the views that need the base template. It was a satisfactory solution,
but I still think it's worth considering allowing template tags to be
loaded before extends.
--
Ticket URL: <https://code.djangoproject.com/ticket/21313#comment:3>
* status: new => closed
* resolution: => needsinfo
Comment:
I guess we could consider a patch, but absent that, I'm going to close
this since there are other ways to accomplish this as described above.
--
Ticket URL: <https://code.djangoproject.com/ticket/21313#comment:4>