Opened 3 years ago

Closed 3 years ago

#18266 closed New feature (wontfix)

Allow context processors to take the context as a second argument

Reported by: fberger Owned by: nobody
Component: Template system Version: master
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

It would be very useful if context processors could do what their name suggests and process the existing context and manipulate it instead of just adding and potentially overriding some existing entries in the context.

This would be useful for context processors that take entries contained in the context and compute an extra bit of information. If the entry is not there it wouldn't waste any time computing it for a view that doesn't need it and avoid extra db queries to get the data.

No guarantee would be given as to the order in which processors run, they could only rely on context data provided by views.

A workaround to achieve the same effect would be to set the context as field in the request.

I've attached a basic patch that allows context processors to optionally take a context argument.

Attachments (1)

diff.patch (759 bytes) - added by fberger 3 years ago.

Download all attachments as: .zip

Change History (3)

Changed 3 years ago by fberger

comment:1 Changed 3 years ago by lukeplant

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

I'm not sure what to do with this.

I can see the use case, but I suspect it is out of scope for the original idea of context processors, and leads to a coupling between your views, which are meant to be specific to one task, and the data returned by context processors which is not. They are always other ways of achieving the same thing - for example your own Context subclass that does this, or computing the data in the view rather than in the context processor.

Also, using inspect.getargspec is not a panacea for backwards compatibility issues - there are many ways that it can fail, especially when decorators or classes are concerned. We would have to treat this as a backwards incompatible change.

comment:2 Changed 3 years ago by jezdez

  • Resolution set to wontfix
  • Status changed from new to closed

Yeah, I agree with Luke, while in theory maybe useful, this seems contrary to what the context processors are supposed to be doing. Closing as wontfix.

Note: See TracTickets for help on using tickets.
Back to Top