Not quite, You should not do
from gluon import *
foo = current.foo
but
from gluon import *
def myfunction():
foo = current.foo
and than call and run myfunction when/where you need.
variable = current.anything
is very dangerous at top level in a module because it is executed when
the module is imported the first time, not for every request. The
first time the a request arrives it works fine. If a second request
arrives in another thread variables will point to the wrong object.
On Oct 13, 10:36 am, Bruno Rocha <rochacbr...@gmail.com> wrote:
> for use the global variables in modules the new recommended way is using
> current object.
>
> in models/***.py
>
> from gluon import current
> current.foo = "bar"
>
> in modules/***.py
>
> from gluon import *
> foo = current.foo
> # current already has session, request, response and T
>
> http://zerp.ly/rochacbruno
> Em 13/10/2011 04:38, "pepper_bg" <ilief...@gmail.com> escreveu:
>
>
>
>
>
>
>
> > Hi,
>
> > I have some helper code in applications/myapp/modules/site_helpers.py.
> > I've been trying to cache the results of some of the functions there.
>
> > The current content is:
>
> > from gluon.shell import exec_environment
> > ee = exec_environment('applications/myapp/models/db.py')
> > cache = ee.cache
> > @cache('cached_result', time_expire = 6000, cache_model=cache.ram)
> > def my_fun():
> > return "stuff"
>
> > Having this I can:
>
> > from applications.myapp.modules.site_helpers import *
>
> > without the exec_environment magic I can't even get this import to
> > work. Now when I call my_fun() I get an error which seems absolutely
> > arbitrary:
>
> > In [1]: from applications.myapp.modules.site_helpers import *
> > In [2]: my_fun()
> > ---------------------------------------------------------------------------
> > TypeError Traceback (most recent call
> > last)
>
> > /pub/web2py/applications/myapp/models/menu.py in <module>()
> > ----> 1
> > 2
> > 3
> > 4
> > 5
>
> > TypeError: action() takes no arguments (4 given)
>
> > Tried using gluon.cache.Cache directly avoiding exec_environment but
> > it needs a Request instance to get created (for which I again seem to
> > need exec_environment).
>
> > So would appreciate it if someone helps me with these two questions:
> > 1. What is the recommended way to use globals like these in the
> > modules code? I see that exec_environment can bring me the model stuff
> > but got the impression that other things (like cache in this example)
> > aren't that easy to get.
> > 2. What is the penalty for using exec_environment? Can I use it freely
> > in helper code placed in /modules (in the book I see a note in that
> > section "While everything discussed here works fine, we recommend
> > instead building your application using components", which am not sure
> > is going to help me in this case)?
>
> > Apologies if what I am asking is obvious. Appreciate your help...
