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.
