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? 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.
