I started to rewrite powerpack :S to make use of this. Just to clarify, this is ok?, this is something that I don't want to change again :P:
current.app = Storage() current.app.settings = Storage() #settings of the current app current.db = DAL(..) current.app.auth = Auth(..) current.app.plugins = PluginManager() current.app.mail = Mail() current.app.service = Service() current.app.crud = Crud() 2011/5/9 Jonathan Lundell <jlund...@pobox.com> > On May 9, 2011, at 9:50 AM, Massimo Di Pierro wrote: > > > > Assuming current.app ... > > > > why > > current.plugins > > instead of > > current.app.plugins > > That would be better, I suppose. > > > > > 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. > > At least if we create current.app and current.app.plugins, we can leave the > local policy (in those items) up to each app or plugin. With the provision > that the plugin's space is actually current.app.plugins.plugin_name > (presumably plugin names within an app can't collide for other reasons). > > Keeping track of the rest of the current.x namespace is an issue, but no > more so than request and the other request-scope globals. Perhaps we should > adopt a convention of adding at least a comment where current is initialized > to document the addition of variables. > > > BTW, in URL() you've coded: > > if hasattr(current,'request'): > r = current.request > > Is there a case where URL is called without current.request being defined? > > > > Also: another reason I'd like to add current.request early in main: I'd > like to simplify rewrite so that it doesn't have to be called with request, > both from main and from URL. > > > > > > 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. > > > -- http://martin.tecnodoc.com.ar
