I come from Pylons, where we had the g globals object. I miss it
dearly.
The Pyramid/Repoze group seems very much into the idea of passing a
request around all the time. I don't like that, mostly from the 'mass
appeal route' , in that its something that just about every other
framework has, and can make Pyramid a bit odd/hard to new people
considering it.
mod_perl had an interesting approach to globals.
- it was often recommended that globals were 'read-only' variables, so
you couldn't change them
- the mp architecture was a little weird. the Apache Master server
started up and had the true 'global' vars. Requests would be handled
by spawned children, up to max-requests, which had their own copy of
globals. Anything they altered would stay global only within that
child ( not affect the master or the other children ). because of
tis , applications built on it tended to do a lot of caching and pre-
compiling on startup to build up a true 'global' datastore... but then
basically never think about writing to the globals -- as there was
little efficiency to be had.
Anyways, if you need to do this again:
The Akhet scaffold has an event subscriber that creates a 'g' globals
object to emulate the pylons environment
https://bitbucket.org/sluggo/akhet/src/6c984e2e24cf/akhet/paster_templates/akhet/%2Bpackage%2B/subscribers.py_tmpl
or you could also just have a little convenience method that just
wraps get_current_registry()
def get_current_settings(field=None):
if field:
return get_current_registry().settings[field]
return get_current_registry().settings
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
