Create Context object in a separate method

[Alex Hill]

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

[Tim Graham]

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.

[Aymeric Augustin]

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.

[Alex Hill]

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

[Aymeric Augustin]

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.

[Aymeric Augustin]

PR: ​https://github.com/django/django/pull/4104

[Aymeric Augustin]

Fixed in master (f2c104ada605d9f7f7b7435778662c16d432dc32) and backported to 1.8.x (9b7b37382cb0e8b5e2d149a3102005bf62016ea3).

[Alex Hill]

Thanks Aymeric, that's perfect!