Opened 11 years ago
Closed 11 years ago
#21313 closed New feature (needsinfo)
load tag before extends
Reported by: | Owned by: | nobody | |
---|---|---|---|
Component: | Uncategorized | Version: | 1.5 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Unreviewed | |
Has patch: | no | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I'd like to be able to load a template tag before extends. I don't want to use a context processor because I don't want every view that uses RequestContext to get the variable. Here's the detailed situation:
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.
Change History (4)
comment:1 by , 11 years ago
follow-up: 3 comment:2 by , 11 years ago
comment:3 by , 11 years ago
Replying to 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.
comment:4 by , 11 years ago
Resolution: | → needsinfo |
---|---|
Status: | new → closed |
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.
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.