m is known as the "request", which represents the runtime context of the template being executed. Its not the same as the HTTP-specific request object r and is mostly agnostic of HTTP. m includes methods for handling output and writing content, calling other components, as well as other services that a template will usually need. The full list of request methods is described in The Request.

ARGS represents a dictionary of all arguments sent to the current component. While a component can specify arguments to be available in the component's namespace via the <%args> tag, the ARGS dictionary contains all arguments supplied to a component regardless of them being named in the <%args> section or not.

In the case of a top-level component called in an HTTP context, ARGS contains the full set of client request parameters. Each field is one of: a string, a list of strings, or for handling file upload objects, a Field object (from the FieldStorage API) or a list of Field objects.

For components called by other components, ARGS contains all the arguments sent by the calling component.

In all cases, the HTTP request arguments, or whatever arguments were originally sent to the request, are available via the request member request_args.

Component arguments are described in Component Arguments - the <%args> tag.

When running Myghty with any of the HTTPHandlers, i.e. ApacheHandler, CGIHandler, WSGIHandler, or HTTPServerHandler, variable r is a reference to either the mod python request object or a compatible emulation object. In the case of ApacheHandler, it is the actual mod_python request. In other cases, it attempts to provide a reasonably compatible interface, including the member variables headers_in, headers_out, err_headers_out, args, content_type, method, path_info, and filename (more can be added...just ask/submit patches). The request object is useful applications that need awareness of HTTP-specific concepts, such as headers and cookies, beyond what the more generic m object provides which attempts to be largely agnostic with regards to HTTP.

Under WSGIHandler, r also contains the member variables environ and start_response, so that an application may also have direct access to WSGI-specific constructs if needed.

s references the Myghty session object. It can also be configured to reference the mod_python session object when running with mod_python 3.1 To use s, you need to turn it on via use_session.

The Myghty session is still available even if s is not configured. See the section Session for full information on the session object.

Myghty supports the addition of any number of global variables that will be compiled into the namespace of all templates. The value of these variables can be specified on a per-application basis or a per-request basis. As of version 0.98, both scopes can be used simultaneously. Per-application globals can be specified via the initial interpreter configurational parameters, or within the httpd.conf file in a mod_python environment. Per-request globals require that the variables be initialized before the Myghty request begins, which requires programmatic "chaining" to the Interpreter via the methods described in Programmatic Configuration.

The two configuration parameters to add global arguments are allow_globals, which specifies a list of global variable names to compile into templates, and global_args, which is a dictionary containing the names of the variables mapped to their desired values. A basic example of programmatic global variables looks like:

import myghty.http.WSGIHandler

def application(environ, start_response):

    handler = myghty.http.WSGIHandler.get_handler(
        allow_globals = ['myglobal'],
        component_root='/path/to/htdocs', 
        data_dir='/path/to/datadirectory'
    )
    
    return handler.handle(
            environ, 
            start_response,
            global_args = {'myglobal' : 'hi'}
    )

Above, all Myghty components will have access to the global variable "myglobal" which has a per-request value of "hi". Note that the allow_globals parameter is only used on the first request, when constructing a new Interpreter object, whereas global_args may be specified for each request.

Another example, using Interpreter:

interpreter = interp.Interpreter(
    allow_globals = ['myglobal'],
    data_dir = '/path/to/datadir',
    component_root = '/foo/components',
)

interpreter.execute("file.myt", 
    global_args = {'myglobal':MyGlobalThingy()}
)

Here is an ApacheHandler example which specifies globals within both scopes:

import myghty.http.ApacheHandler as ApacheHandler

# create per-application global object
appglobal = 'myappglobal'

def handle(req):
    # create per-request global object
    myglob = MyGlobal(req)
    
    handler = ApacheHandler.get_handler(
            req, 
            allow_globals = ['appglobal', 'myglobal'],
            global_args = {'appglobal' : appglobal}
    )
            
    return handler.handle(req, global_args = {'myglobal':myglob})

Here is an application-scoped global added in a mod_python environment via the httpd.conf file:

# specify list of global variable names
PythonOption MyghtyAllowGlobals ['myglobal']

# specify the value of the global variable
PythonOption MyghtyGlobalArgs "{'myglobal':  \
    __import__('mystuff.util').util.MyGlobalThingy()}"