Myghty Documentation
Version: 1.2 Last Updated: 07/07/10 12:55:17
View: Paged  |  One Page

an autohandler is an optional file, by default named autohandler, that will serve as the base inheriting template for all requests within a directory and its subdirectories. Inheritance is discussed in more detail in the section Inheritance. The basic idea is that the autohandler template executes first; it runs some code and/or outputs some HTML, and then calls a special method to deliver the content of the requested template. When the embedded template has completed its execution, the autohandler can then output some more HTML at the bottom and/or execute cleanup code:

<head>autohandler demo</head>
% m.call_next()

Autohandlers are searched for first in the current directory, then upwards in the enclosing directories, until the component root is reached. If more than one autohandler is found, they will all be executed within each other, with the most directory-specific autohandler executed at the innermost level. Any page or autohandler can deny the execution of an enclosing autohandler by setting the "inherit" flag to be None.

Autohandlers are ideal for standardized HTML enclosing schemes as above. There are also many more creative uses. An autohandler that automatically protects a whole directory based on a custom login scheme would look something like this:

# autohandler

<%python scope="init">
    # look in the apache request for some kind of 
    # login token
    user = login_manager.check_login(r)
    if not user:
        # redirect out of here, the rest of the content
        # in this page will not be sent
        m.send_redirect("/login.myt", hard=True)

        # otherwise, they are ok, deliver content
back to section top

A dhandler, otherwise known as a directory handler, is a file, by default named dhandler, that serves requests for which the requested Myghty template can not be located, or for a request that names a directory by itself without a file. dhandlers are searched for similarly to autohandlers, i.e. in the innermost enclosing directory first, then upwards towards the component root. However, only one dhandler is executed at a time. The code within the dhandler has access to the request member dhandler_path which refers to the path information for the requested (but unlocated) component, relative to the path of the current dhandler. It also can call decline which will abort the current dhandler and search up the directory tree for the next enclosing dhandler.

Dhandlers are good for special path-based requests used in places such as news sites who want to have clean URLs that have no query strings, for writing components that process the contents of a directory dynamically, such as image or filesystem browsers, or custom per-directory "file not found" handlers.

Example: content management system. A lot of news sites have fancy URLs with dates and article keywords (sometimes called slugs) specified within them. These URLs sometimes are resolved into database parameters, and the actual content is retrieved from some source that is not the same as a local file with that path scheme. This example extracts tokens from a URI and uses them as parameters to retrieve content.

# Hypothetical URL:

# dhandler, inside of the web directory /news/

<%python scope="init">
    import re
    # get path
    path = m.dhandler_path
    # get arguments from the path
    match = re.match(r"(\d+)\/(\d+)\/(\d+)\/(\w+)\.myt", path)
    if match:
        (year, month, day, slug) = match.groups()
        # look up a news article in a 
        # hypothetical content-management database 
        # based on this parameters from the path
        article = db.lookup(year, month, day, slug)
        article = None
    if article is None:
        # improper URL, or no article found
        m.send_redirect("article_not_found.myt", hard=False)

<!-- display the article -->

<h3><% article.get_headline() %></h3>

<% article.get_text() %>

The tricky part about a dhandler in conjunction with Apache is that the URL used to access the dhandler has to be identified by apache as a Myghty request. For a basic setup that associates *.myt with Myghty files, the URL used to access the dhandler would have to end with the string ".myt". To call dhandlers more flexibly, you would have to insure that Apache is configured to send all requests for a particular directory to Myghty for processing, using a directive like DirectoryMatch or FilesMatch.

back to section top
Using Module Components for autohandler/dhandler

First described in Module Components, these components can also be used as autohandlers or dhandlers. Simply configure the Myghty environment to recognize paths with "autohandler" and/or "dhandler" as module component paths:

module_components = [
    # configure the root autohandler to resolve to Autohandler class
    {r'/autohandler$' : 'modcomp:Autohandler'},
    # configure all dhandlers to resolve to Dhandler class
    {r'.*/dhandler$' : 'modcomp:Dhandler'},

In particular, code-intensive autohandlers and dhandlers such as content delivery mechanisms, translation components, or authentication controllers would be suitable as module components. Also see the section Advanced Resolver Configuration for more information on the resolution of autohandlers and dhandlers.

back to section top