Opened 17 years ago

Closed 15 years ago

#3818 closed (wontfix)

Expose chosen settings to default context processor.

Reported by: ciantic@… Owned by: Adrian Holovaty
Component: Core (Other) Version: dev
Severity: Keywords: expose_settings
Cc: Triage Stage: Design decision needed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Gives user an ability to expose wanted settings to the default context processors, and when you control it from settings.py the only security risk is: stupid settings creator. Also it gives you control what to expose, if in future user might want to expose something else from there too.

settings.py:
EXPOSE_SETTINGS = ('MEDIA_URL', 'ADMIN_MEDIA_PREFIX', 'LANGUAGE_CODE')
It could be set by default to that.

There is no point to write multiple settings reading context processors, this is the settings context processor. If your application needs some other setting, then you expose it to the app.

Attachments (2)

context_processors.diff (420 bytes ) - added by ciantic@… 17 years ago.
exposed context processor that handles reading of settings in context wise
context_settings.diff (1.1 KB ) - added by m@… 15 years ago.
context processor for exposing settings in templates.

Download all attachments as: .zip

Change History (6)

by ciantic@…, 17 years ago

Attachment: context_processors.diff added

exposed context processor that handles reading of settings in context wise

comment:1 by Chris Beaven, 17 years ago

Triage Stage: UnreviewedDesign decision needed

It's come up before, but this is a slightly different take.

comment:2 by Adrian Holovaty, 17 years ago

Resolution: duplicate
Status: newclosed

Duplicate of #1278, which has been marked as a wontfix.

comment:3 by m@…, 15 years ago

Resolution: duplicate
Status: closedreopened

I don't think this is a duplicate of the MEDIA_URL ticket.

I think that it would simplify some development scenarios to be able to expose selected settings in the templates instead of having to write one-off context processors for every single one. This seems particularly useful for people who have custom settings. My usecase for this is a Google Analytics ID - I don't want GA to fire while I'm doing testing on my dev machine, so my dev settings.py has GA_ID set to "FOO" while the prod on has the real ID, and in my template I simply have {{ settings.GA_ID }}

I'm attaching a patch that is similar to the original one, with two differences:

  1. settings are placed in a context dict named 'settings' to avoid collisions and to improve readability, so a setting would be accessed from the template as {{ settings.FOO }}
  2. I've added the suggested defaults to global_settings.py

by m@…, 15 years ago

Attachment: context_settings.diff added

context processor for exposing settings in templates.

comment:4 by Russell Keith-Magee, 15 years ago

Resolution: wontfix
Status: reopenedclosed

This was marked Wontfix for a reason, and your patch doesn't address that reason.

The solution to every problem isn't "add a new setting". In this case, the solution is "write your own context processor".

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