The app object is a proxy that delegates to the active RumApp or None if there’s no active app.
When in the context of handling a WSGI request, the RumApp that is handling it registers itself at this proxy automatically. It is threadsafe and re-entrant, that is, a RumApp can delegate the response process to another RumApp instance (or even itself) and these won’t collide.
However, if you need to access an app’s services from outside the scope of a request, or when you’re not delegating the response process to it, (eg: when requesting a view for some resource from another WSGI app’s controller action) you must make sure that the app you’re using becomes the active app while execution is inside the RumApp.
To do this in python 2.6 or python 2.5 (with from __future__ import with_statement) you can do:
rum_app = RumApp(....)
with rum_app:
form = rum.app.get_view(obj, action='edit')
form_output = form(obj)
In earlier versions of python you can achieve the same effect like this:
rum_app = RumApp(....)
def get_form_output(obj, action):
form = rum.app.get_view(obj, action=action)
return form(obj)
form_output = rum_app.call_in_context(get_form_output, obj, 'edit')