Assuming current.app ... why current.plugins instead of current.app.plugins
but yes to current.app.auth I think we need a policy before we decide on a case by case basis but I have not given much thought to the matter. On May 9, 9:07 am, Jonathan Lundell <jlund...@pobox.com> wrote: > 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.
