calling functions from another controller

[Marco Prosperi]

hello everybody, what do I have to import and wich syntax should I use
to call in controllerA.py the function myfun defined in
controllerB.py?

thanks, Marco

[srackham]

You could use the exec_environment function to build an execution
environment in controllerA:

from gluon.shell import exec_environment
controllerB=exec_environment('applications/myapp/controllers/
controllerB.py')
result=controllerB.myfun()

If myfun() needs to access the current request, response or
session you'll need to inject them into the environment
before calling myfun(), e.g.:

controllerB.request=request

Be careful of myfun() side effects though.

Have you considered moving shared helpers to a dummy library
application that is specifically for shared resources? You
can then use the same technique, for example:

helpers=exec_environment('applications/library/modules/helpers.py')
result=helpers.myfun()

XML-RPC is another way to call controller functions, it's
easy to do in web2py (there's an example on the web2py
website
http://mdp.cti.depaul.edu/examples/default/examples#xmlrpc_examples)

XML-RPC is particularly attractive because you get a clean
Web API and you are not limited to executing it locally,
the overhead is higher though.

Cheers, Stuart

[Marco Prosperi]

thanks for the complete answer. On my web2py 1.35 I haven't a
exec_environment function but there seems to be one in 1.37 version.
To upgrade my web2py version on webfaction do I have to reinstall
everything with the script indicated in the faq or a simpler approach
is available?

Marco

On 6 Lug, 14:23, srackham <srack...@gmail.com> wrote:
> You could use the exec_environment function to build an execution
> environment in controllerA:
>
> from gluon.shell import exec_environment
> controllerB=exec_environment('applications/myapp/controllers/
> controllerB.py')
> result=controllerB.myfun()
>
> If myfun() needs to access the current request, response or
> session you'll need to inject them into the environment
> before calling myfun(), e.g.:
>
> controllerB.request=request
>
> Be careful of myfun() side effects though.
>
> Have you considered moving shared helpers to a dummy library
> application that is specifically for shared resources? You
> can then use the same technique, for example:
>
> helpers=exec_environment('applications/library/modules/helpers.py')
> result=helpers.myfun()
>
> XML-RPC is another way to call controller functions, it's
> easy to do in web2py (there's an example on the web2py

> websitehttp://mdp.cti.depaul.edu/examples/default/examples#xmlrpc_examples)

[Marco Prosperi]

thanks for the complete answer. On my web2py 1.35 I haven't a
exec_environment function but there seems to be one in 1.37 version.
To upgrade my web2py version on webfaction do I have to reinstall
everything with the script indicated in the faq or a simpler approach
is available?

Marco



On 6 Lug, 14:23, srackham <srack...@gmail.com> wrote:

> You could use the exec_environment function to build an execution
> environment in controllerA:
>
> from gluon.shell import exec_environment
> controllerB=exec_environment('applications/myapp/controllers/
> controllerB.py')
> result=controllerB.myfun()
>
> If myfun() needs to access the current request, response or
> session you'll need to inject them into the environment
> before calling myfun(), e.g.:
>
> controllerB.request=request
>
> Be careful of myfun() side effects though.
>
> Have you considered moving shared helpers to a dummy library
> application that is specifically for shared resources? You
> can then use the same technique, for example:
>
> helpers=exec_environment('applications/library/modules/helpers.py')
> result=helpers.myfun()
>
> XML-RPC is another way to call controller functions, it's
> easy to do in web2py (there's an example on the web2py

> websitehttp://mdp.cti.depaul.edu/examples/default/examples#xmlrpc_examples)

[Massimo Di Pierro]

It is ok to just copy over the gluon folder and restart

[Stuart Rackham]

Marco Prosperi wrote:
> thanks for the complete answer. On my web2py 1.35 I haven't a
> exec_environment function but there seems to be one in 1.37 version.
> To upgrade my web2py version on webfaction do I have to reinstall
> everything with the script indicated in the faq or a simpler approach
> is available?

I don't know about webfaction but on my local PC I prefer using the
development version from http://code.google.com/p/web2py/ mainly because
it's much easier to update from the SVN repository.

I keep 'web2py' in `~/bin` separate from my 'web2py' applications
which I keep in `~/projects/web2py/applications`.

# Checkout the latest web2py trunk.
$ cd ~/bin
$ svn checkout http://web2py.googlecode.com/svn/trunk/ web2py

# Set admin password and installs example apps.
$ cd web2py
$ python web2py.py

# Link any existing web2py applications.
$ cd applications
$ ln -s ~/projects/web2py/applications/* .

To update:

$ cd ~/bin/web2py
$ svn update

Cheers, Stuart

[Massimo Di Pierro]

Yes but mind that bugs sometime get in the development trunk. It is ok
for people who want to help developing web2py but users should stick
to stable.

[Marco Prosperi]

again on the original question: after moving the function in
applications/library/modules/helpers.py I get an error on a line like
this:

A('blabla', _href=URL(r=request,f='function'))

and the error is

SyntaxError: not enough information to build the url

do I have to specify the controller with c=? but which is the
controller here? c='helpers' doesn't work

thanks in advance,
Marco

[Massimo Di Pierro]

I assume you are importing applications/library/modules/helpers.py
where is

> A('blabla', _href=URL(r=request,f='function'))

?

If it is in applications/library/modules/helpers.py than it is likely
you are not passing the request to the function in the module.

[achipa]

You can always make a stable branch and just do svn merge there, so
the svn update pulls in only the stable updates. In fact, that's
exactly what I'm doing on my working copy O:)

[Marco Prosperi]

in applications/library/modules/helpers.py I have

def myfun():
...

A('blabla', _href=URL(r=request,f='function'))

....

def function():
....


while in the controller default.py of my init application I have:

helpers=exec_environment('applications/library/modules/helpers.py')
getresult=helpers.myfun

and then I call getresult()

[Stuart Rackham]

You need to either inject the current environment's request (if that's
what's expected):

helpers.request=request

Or add request details to the environment's existing request, for example:

helpers.request.folder='applications/examples/'

Cheers, Stuart

[Massimo Di Pierro]

You are treating a module as a controller. You cannot do that. You
need to use helpers.py as a module and import all the symbols you use

> in applications/library/modules/helpers.py
> from gluon.html import *
> def myfun(request):

> ...
> A('blabla', _href=URL(r=request,f='function'))
> ....
>
> def function():
> ....
>
>

> while in the controller default.py of my init application:
>
> import applications.library.modules.helpers as helpers
> getresult=helpers.myfun
>
> and then call getresult(request)

[Massimo Di Pierro]

This will work too but I think that a file in modules should be a
module and not executed in a web2py environment.

[Stuart Rackham]

Massimo Di Pierro wrote:
> This will work too but I think that a file in modules should be a
> module and not executed in a web2py environment.

This wouldn't this prohibit helpers that require dynamic environment
objects e.g. timesince() uses T
(http://mdp.cti.depaul.edu/AlterEgo/default/show/130)

or should all helpers be explicitly passed any required dynamic objects?

[Massimo Di Pierro]

The only things that need to be passed are request, response,
session, cache and T

everything else can just be imported.

The reason is that stuff in a module should not be really translated
in the module because they should not hardcode strings. Strings
should be passed already translated. I would just put timesince in a
model file and give it an appropriate name to make things simpler.

Massimo

[Stuart Rackham]

This is a great bit of best practice advice.

Makes the use of exec_environment() inadvisable for helpers, it's much
better to explicitly pass the environment as function args and use the
Python module import statement.