ModjyAppImportable
Version 2 (Alan Kennedy, 02/25/2011 09:15 pm)
| 1 | 1 | h1(#import_mechanism). The importable name mechanism. |
|
|---|---|---|---|
| 2 | 1 | ||
| 3 | 2 | Alan Kennedy | There are two different mechanisms by which you can specify a WSGI application to modjy. This page describes the *importable* mechanism. The [[ModjyAppExecFile|execfile mechanism]] is described on a different page. |
| 4 | 1 | ||
| 5 | 1 | The *importable* mechanism uses a single string which specifies an importable name, which when imported should deliver a python callable object. As described above, this can be "any python callable":http://docs.python.org/ref/calls.html. The importable name is specified as a single string. However, there are some small variations on how that string is specified, depending on the nature of the callable. |
|
| 6 | 1 | ||
| 7 | 1 | # *Simple callable*: if the target application is directly callable, e.g. a simple function, then you need only specify the name of the callable/function, and it will be called directly by modjy. Example: *some_framework.web.handlers.WSGIHandlerFunction* |
|
| 8 | 1 | # *Instance*: if the target application is an instantiable object, e.g. a class, then it will need to be "instantiated":http://www.faqs.org/docs/diveintopython/fileinfo_instantiation.html before it can be called. To do this, supply parentheses/brackets after the name. Example: *some_framework.web.handlers.WSGIHandlerClass()*. In this case, modjy will locate the definition of the *WSGIHandlerClass* in *some_framework.web.handlers*, create an instance of that class, and use that as the application. Note that when the application instance is called to service a WSGI request, the method that will be invoked is the *__call__* method. |
|
| 9 | 1 | # *Instance method*: if you want to use a class instance to service WSGI requests, but need to specify a specific method, then add the handler method name onto the end of the importable name. Example: *some_framework.web.handlers.WSGIHandlerClass().handler*. With this example, modjy will locate the WSGIHandlerClass, as described above, create an instance of it, and then use the *handler* method of that instance as that application callable. |
|
| 10 | 1 | ||
| 11 | 1 | h2. The importable name mechanism and reloading |
|
| 12 | 1 | ||
| 13 | 1 | *Reloading is not supported with the importable name mechanism*. When the importable name mechanism is used, the value of the *reload_on_mod* parameter is *ignored*. |
|
| 14 | 1 | ||
| 15 | 1 | h2. The importable name mechanism and caching |
|
| 16 | 1 | ||
| 17 | 1 | Caching means that the same application callable object will be re-used repeatedly, to save object creation overhead. You have the choice of whether or not to enable caching using the *cache_callables* parameter, described in the [[ModjyConfiguration|modjy configuration reference]]. |
|
| 18 | 1 | ||
| 19 | 1 | If caching is *disabled* when using the importable name mechanism, this means that a new application object will be created for every new request, when appropriate. When the application is a simple callable, as described above, then caching has no meaning, since there is no instance to be re-used. When the application is an *instantiable*, as described above, then new instances will be created for every request. |
|
| 20 | 1 | ||
| 21 | 1 | If caching is *enabled* and the application callable is a class instance, then the same instance will be reused for every single request. |