#24234 closed Cleanup/optimization (fixed)
Create Context object in a separate method
Reported by: | Alex Hill | Owned by: | nobody |
---|---|---|---|
Component: | Template system | Version: | 1.8alpha1 |
Severity: | Normal | Keywords: | multiple-template-engines |
Cc: | Triage Stage: | Ready for checkin | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | yes | UI/UX: | no |
Description
In 1.8, django.templates.backends.django.Template.render
accepts a context dict, and uses that to instantiate a Context (or RequestContext) object before passing it to the actual DTL template's render()
.
I'd like to break the Context-creation code into its own method so that I can call it from my library DjPj, as I do with TemplateResponse.resolve_context
in 1.7 and below.
It's a very small patch: https://github.com/AlexHill/django/compare/stable/1.8.x?diff=split#diff-6492e208d64b891c181c85a794d0b303R58
Change History (9)
comment:1 by , 10 years ago
Keywords: | multiple-template-engines added |
---|---|
Patch needs improvement: | set |
Triage Stage: | Unreviewed → Accepted |
Type: | Uncategorized → Cleanup/optimization |
comment:2 by , 10 years ago
One of the goals of the Multiple Template Engines project was not to give preferential treatment to the Django Template Language. I wouldn't like to document a specific API in the Django backend.
If you ignore all the deprecation stuff, you end up with a few lines of straightforward code that you could easily copy-paste in DjPj:
if request is None: context = Context(context) else: # The following pattern is required to ensure values from # context override those from template context processors. original_context = context context = RequestContext(request) if original_context: context.push(original_context)
Extracting all the logic from render
into another function doesn't make a lot of sense either.
Count me as -0 here.
comment:3 by , 10 years ago
Resolution: | → wontfix |
---|---|
Status: | new → closed |
comment:4 by , 10 years ago
Hi Tim, Aymeric,
Thanks for your feedback. This is highly specific to DTL, definitely wouldn't want to document it.
I feel that
- resolving the context argument into a
Context
is a clearly-defined task suitable for delegation to a function - it's independently useful (as in my case) outside of
Template.render
- it existed in standalone form before 1.8 in the form of
TemplateResponse.resolve_context
, which might be used by others than me. Putting it in a separate function makes for a straightforward migration. - edit: well-commented copy-paste will be a fine alternative but doesn't quite capture "create a
Context
exactly as Django does" as clearly and succinctly.
Would love it if you could be swayed to a +0.
Either way, thanks for the huge job you've done on the multiple template engine support, this minor inconvenience notwithstanding :)
Cheers
Alex
comment:5 by , 10 years ago
Resolution: | wontfix |
---|---|
Status: | closed → new |
What could make sense is extracting a utility function in django.template.context to encapsulate this weird pattern:
def make_context(request, context): if request is None: context = Context(context) else: # The following pattern is required to ensure values from # context override those from template context processors. original_context = context context = RequestContext(request) if original_context: context.push(original_context)
And then use it in django.template.backends.django.Template.render.
comment:6 by , 10 years ago
Patch needs improvement: | unset |
---|
comment:7 by , 10 years ago
Triage Stage: | Accepted → Ready for checkin |
---|
comment:8 by , 10 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Fixed in master (f2c104ada605d9f7f7b7435778662c16d432dc32) and backported to 1.8.x (9b7b37382cb0e8b5e2d149a3102005bf62016ea3).
Tentatively accepting, pending feedback from Aymeric. However, I don't think adding an underscore method is the best solution if there is a need for a public API here.