On May 9, 2011, at 6:52 AM, Massimo Di Pierro wrote: > > I agree. But should be call it application? Fir of all the settings > are request level, not app level. And it may create confusion between > > current.application > current.request.application > > how about one of the following: > current.info > current.settings > current.parameters > current.storage > > and we set it by default?
We could name it current.app instead. My rationale for "application" (or "app") is that the application controls its internal namespace. The other names are fine as long as we're clear about whether the namespace is "owned" by gluon or the application. It's not obvious from the names (info, settings, parameters, storage) who controls each namespace. I also suggest current.plugins, with a convention that a plugin named 'xyz' would use current.plugins.xyz as the base of its namespace in current, so as not to conflict with either gluon or the application. > > On May 9, 8:37 am, Jonathan Lundell <jlund...@pobox.com> wrote: >> On May 9, 2011, at 6:24 AM, Massimo Di Pierro wrote: >> >> >> >> >> >> >> >> >> >> >> >>>> Jonathan actually mentioned having a current.application Storage that would >>>> store things like auth and db that are created in models. I would REALLY >>>> like to see this. I still need to have my z_import_modules.py in order to >>>> to >>>> set these things manually to current. I understand that it's easy enough to >>>> set these yourself at the end of db.py, but having a standardized Storage >>>> object with these variables would be better in the long run. >> >>> If I understand.... you can already do >> >>> current.db=DAL(...) >>> current.auth=Auth(db) >> >>>> My only other thing is: How much effort would it take to get the Storage >>>> class to be imported when you call "from gluon import *"? >> >>> The question is pollution of name space. Otherwise it takes nothing to >>> do. What do people think about this? >> >> You can of course stick anything at all into current, but it will create >> namespace problems down the road. That's the point of having >> current.application = Storage() in current's initialization: to set aside >> some application-managed namespace. >> >> It's certainly possible that we want other semi-standard names as well (db & >> auth, for example), but an application shouldn't arbitrarily add items to >> current, since there's no guarantee that gluon won't use the same names in >> the future.
