The ApacheHandler handles mod_python requests. It retrieves configuration via directives found in the host's httpd.conf file in the manner detailed in mod_python, and by default serves the component referenced by the request.uri data member. Configuration parameters sent programmatically override those found in the Apache configuration.

In the example below, a file "myghty_handler.py" is created, which contains a very simple mod_python handler that "chains" to the myghty ApacheHandler.

import myghty.http.ApacheHandler as ApacheHandler
from mod_python import apache

def handle(request):
    handler = ApacheHandler.get_handler(request)
    return handler.handle(request)

A configuration for the above file is similar to a straight Apache configuration. Since the ApacheHandler created in the myghty_handler.py file contains no configuration at all, all of its options will come from the httpd.conf directives:

AddHandler mod_python .myt
PythonHandler myghty_handler::handle
PythonPath "sys.path+[r'/path/to/my/libraries']"
PythonOption MyghtyComponentRoot r"/path/to/htdocs"
PythonOption MyghtyDataDir r"/path/to/writeable/data/directory/"

When we take the above handler file and add configuration directives programmatically, they will override those named in the httpd.conf file:

import myghty.http.ApacheHandler as ApacheHandler
from mod_python import apache

def handle(request):
    handler = ApacheHandler.get_handler(request,
            data_dir='/usr/local/web/data',
            component_root=[
                {'components':'/usr/local/web/components'},
                {'templates':'/usr/local/web/templates'}
            ])
    return handler.handle(request)

Another example, overriding the application's data directory, and also the request's component path and request arguments:

import myghty.http.ApacheHandler as ApacheHandler
from mod_python import apache

def handle(request):
    handler = ApacheHandler.get_handler(
        request, interpreter_name = 'mainhandler', data_dir = '/data'
    )
    return handler.handle(request, 
        component = 'mypage.myt', request_args = {'foo' : 'bar'}
    )

The above example also specifies the interpreter_name configuration parameter which identifies which ApacheHandler is returned by get_handler. If this parameter is not specified, it defaults to "main".

The CGI handler retreives its environment information via the cgi.FieldStorage() method as well as os.environ. Configuration parameters sent programmatically override those found in the CGI environment. By default, CGIHandler serves the component indicated by the environment variable PATH_INFO.

#!/usr/local/bin/python

import myghty.http.CGIHandler as CGIHandler

# serve the component based on PATH_INFO
CGIHandler.get_handler(
        component_root='/path/to/htdocs',
        data_dir='/path/to/datadirectory'
).handle()

WSGIHandler works similarly to CGIHandler. Its r object maintains a reference to both the environ and start_response members. These members are used to extract the core data members of the r object, such as headers_in, method, etc.

When running under WSGI, the environ and start_response variables are available via:

# WSGI environment variables

r.environ
r.start_response

import myghty.http.WSGIHandler as WSGIHandler

def application(environ, start_response):
    return WSGIHandler.get_handler(
        component_root='/path/to/htdocs', 
        data_dir='/path/to/datadirectory').handle(environ, start_response)

Also supported with WSGI is the standard application(environ, start_response) function, which takes in all application and request-scoped configuration parameters via the environ argument:

import myghty.http.WSGIHandler as WSGIHandler

params = dict(
    interpreter_name='main_wsgi',
    component_root='/path/to/htdocs', 
    data_dir='/path/to/datadirectory'
)

def application(environ, start_response):
    environ['myghty.application'] = params
    environ['myghty.request'] = {'component' : 'mycomponent.myt'}
    return WSGIHandler.application(environ, start_response)

Chaining to the Interpreter directly also allows Myghty to run outside of a web context completely, within any Python application. It doesnt really need much configuration to run in "barebones" mode; the two most common features are the component root, which specifies one or more roots to search for input files, and the optional data directory, where it will store compiled python modules. Without the data directory, the compiled python modules are created in memory only.

A standlone application to run Myghty templates looks like this:

#!/usr/local/bin/python

import myghty.interp as interp
import sys

interpreter = interp.Interpreter(
        data_dir = './cache',
        component_root = './doc/components',
        out_buffer = sys.stdout
    )

# component name is relative to component_root
interpreter.execute('/index.myt')

The execute method of Intepreter takes optional parameters and sends them off to a newly created Request object. You can specify any of the constructor arguments used by Request or its embedded helper object RequestImpl in the execute call of Interpreter, which will override the values given in the constructor to Interpreter. The below example sends a buffer to each request with which to capture output, via the out_buffer parameter:

file = open('index.html', 'w')
interpreter.execute('/index.myt', out_buffer = file)
file.close()