Groovie

History

Myghty first came into existence a little over a year ago when Mike Bayer looked around at the Python web application frameworks and couldn’t find one that really sucked him in. Having used Mason for various projects, but not finding anything as elegant as it for Python he decided to port Mason to Python.

This ported code was based on the Perl code almost line by line, resulting in a Python web application framework that worked almost exactly like Mason, except with Python as the base language. It wasn’t very long before Mike started adding to Myghty, such as Module Components, and threaded features not found in Mason.

Terms Used

MVC – Model, View, Controller paradigm is typically used to describe an approach that separates the code in these 3 steps rather than mingle them all in one place. Model usually refers to the database and its abstraction, the Controller handles the logic of dealing with the request, getting the data from the Model, and passing it to the View for display to the user.

Component – A component in Mason is what a template is known as. A template might display a full web-page, just one small section, or send data to other components. Components typically correspond to files on a filesystem, and appear as normal HTML pages with a few lines of Python in them, although they’re far from normal HTML pages…

Resolver – Used to describe the process of determining what to do with a given URL. Myghty has some incredible flexibility here.

Distinctive Features

Module Components

In Python, your modules contain all your Python code. In Myghty, the Component contains a mixture of Python with HTML. To handle a MVC approach to development, Myghty has Module Components. These are a cross of a Myghty Component with a Python Module, that leaves you with a fairly normal Python Module. It’s called directly from Myghty in a similar way to how Myghty would call a Component. These Module Components can be explicitly defined in the configuration, or called implicitly.

module_components = [
    {r'myapplication/home/.*' : 'myapp.home:HomeHandler'}, 
    {r'myapplication/login/.*' : 'myapp.login:LoginHandler'}, 
    {r'.*/cart' : 'myapp.cart:process_cart'}, 
    {r'.*' : 'myapp.home:HomeHandler'} 
]

This would map the URL http://yourapp/myapplication/home/blah to the HomeHandler component class, in the home module file, under the myapp package. The method in the HomeHandler class called can be done in two different ways, implicitly, or explicitly. For more details on this, read the Myghty docs on Module Components

While other frameworks implement an MVC approach, Myghty’s goes a step farther by letting you tie it into the resolution options used by the Resolver, and even use your own resolvers…

Advanced Resolver

In version 0.97alpha2 (maybe a better naming scheme could be used? :) the resolver implementation was heavily rewritten to allow massive flexibility in how a URL is handled. When Myghty handles a request, it goes through a fairly complex process to determine what to do with it. This is called the default strategy:

1. Translate the URL against the path translation options – This can act as an internal URL rewriting scheme, changing a URL to be handled differently
2. Resolve a dhandler – This rule matches conditionally. It is only called if the rules under it don’t find a match, it then strips off part of the URL its looking for and adds dhandler. So a search for /article/view/38 becomes a search for /article/view/dhandler if 38 isn’t found. Read more about dhandlers
3. Check the URI Cache – The URI cache is searched for the incoming URI at this point, to see if a component has matched it before. This rule is also executed on a conditional basis.
4. Upwards Search – The 3rd conditional rule of the bunch, this rule is called during inheritance when a component searches parent paths for an autohandler. Read more about autohandlers
5. Resolve a Module – Matches a Module Component to the incoming URI.
6. Resolve a File – Matches a file under the component roots specified for a match to the incoming URI. This will directly call a Myghty template file on the system in response to a URL.

As soon as any of the non-conditional rules matches, the file or module component method is served up. Myghty gets an additional speed boost by keeping compiled versions of all your template files around, so that they’re only compiled the first time they’re called. By using the basic Python way of compiling the templates as .pyc files, it also ensures that they’re re-compiled the second you update one of them. This way you’re always sure you’re viewing the latest update of your template.

So where’s the real power in all this?

These are just the default rules. They can be completely, and utterly customized. You can switch the order around, you can remove resolver rules entirely, and you can even write your very own resolver rules.

Maybe you’ve decided you want to serve some of the components from a database instead of the file system. You could write a custom resolver rule that does just that, and loads the entire component from the database as well. You could write your own version of the Path Translate module to get its rewrite rules from a database table. As if this wasn’t powerful enough, Myghty also lets you have different resolver strategies for different contexts.

Conclusion

Myghty is a very powerful web framework. It has features that go beyond any pure “templating” language I’ve encountered. If you’re not quite happy with what you’re using right now, or something I described above makes you giddy with thoughts of power, maybe its time to take Myghty for a test drive.

In future posts, I’ll describe more of the features I use daily in Myghty, and share code tidbits that let you get complex tasks done easily.

He wrote a Python script that sent RSS updates over the LAN to Growl (Note: The Python script requires netgrowl.py). While that was cool, his method of adding feeds to watch (editing a text file on a remote machine) didn’t seem that cool. It was about that time that I started thinking, well, why not have Net News Wire manage the feeds? That is what its for after all… so I started looking to see how I could tie this togther.

Searching through ranchero.com quickly led me to a page on calling scripts as subscriptions. So I figure, if I write an AppleScript, that searches a NetNewsWire (NNW) folder for unread items then sends them to Growl via the Applescript interface, that should do the trick.

So without further ado, here’s my little Applescript, based on Brent Simmons Folder Watch example, that searches a NNW folder for unread items, sends them to Growl, then marks them as read.

Installing

GrowlRSS.scpt:

Download this where desired, add it as a script in NNW using the File menu -> New Special Subscription -> Script. Then locate the GrowlRSS script, it will then open the Show Info window. Expand the Script Settings option, and put the name of the NNW folder to watch as the Args. Close, and hit refresh, and it should send any unread items in that folder to Growl.

Caveat

You should have Growl 0.6 from svn installed. It’s possible it’ll work with 0.5, but I haven’t tested that.

First, the things you should have installed on your system (which I’m assuming is nix):

#!/usr/bin/perl
use FindBin qw($Bin);
use lib "$Bin/modules";

use strict;
use HTML::Mason::CGIHandler;
use MIME::Lite;  # Need this to e-mail the error

# Enter CGI::Fast mode, which should also work as a vanilla CGI script.
require CGI::Fast;

my $h;
my $show_error = 1;  # Should we e-mail the error, or dump to the web?

if ($show_error) {
    $h = HTML::Mason::CGIHandler->new
        ( comp_root => [
              [main => "/usr/local/www/GroovieWebapp/site"],
              [libs => "/usr/local/www/GroovieWebapp/libs"]
          ],
          data_dir => "/usr/local/www/GroovieWebapp/mdata",
          allow_globals => [qw($Schema $Session)]
        );
} else {
    $h = HTML::Mason::CGIHandler->new
        ( comp_root => [
              [main => "/usr/local/www/GroovieWebapp/site"],
              [libs => "/usr/local/www/GroovieWebapp/libs"]
          ],
          data_dir => "/usr/local/www/GroovieWebapp/mdata",
          error_format => 'text',
          error_mode => 'fatal',
          allow_globals => [qw($Schema $Session)]
        );
}

# Setup our global vars for the request, preload our modules
{ package HTML::Mason::Commands;
  use Apache::Session::File ();    # My favorite for session tracking
  use CGI::Cookie;                 # Also for session tracking
  use DBI;   # It's nice to load and establish our db connection in advance
  DBI->install_driver("mysql");  # Put in whatever connection you use, etc.

  # This allows our $Schema variable to be accessed from anywhere in our Mason site
  our $Schema = DBI->connect_cached("dbi:mysql:DB_NAME","DB_USER", "DB_PASSWORD" );
}

# These two subroutines add Mason functionality that was lost by using CGIHandler instead
# of the ApacheHandler.
sub HTML::Mason::FakeApache::document_root {
    my $self = shift;
    return $ENV{'DOCUMENT_ROOT'};
}
sub HTML::Mason::FakeApache::param {
    my $self = shift;
    my $key = shift;
    my %args = HTML::Mason::Utils::cgi_request_args($self->query,$self->query->request_method);
    my @keys = (keys %args);

    if ($key) {
        return $args{$key};
    } else {
        return @keys;
    }
}

# For e-mailing the error
sub send_email {
    my $error = shift;
    my $cgi = shift;
    my $site = $cgi->virtual_host();
    my $time = localtime;
    my $body = "----------------------------------------\n";
    $body   .= "-------- ERROR OCCURRED\n";
    $body   .= "----------------------------------------\n";
    $body   .= "\n\n";
    $body   .= "WEBSITE INFO\n";
    $body   .= "Site: $site\n";
    $body   .= "Full URI Request: ".$ENV{'REQUEST_URI'}."\n";
    $body   .= "Time: $time\n";
    $body   .= "\n\n";
    $body   .= "USER INFO\n";
    $body   .= "Referrer: ".$cgi->referer()."\n";
    $body   .= "User-agent: ".$cgi->user_agent()."\n";
    $body   .= "IP Address: ".$cgi->remote_host()."\n";
    $body   .= "Cookie info: ".$cgi->raw_cookie()."\n";
    $body   .= "\n\n";
    $body   .= "MASON ERROR\n";
    $body   .= $error;

    my $msg = MIME::Lite->new( From    => 'YOUR SITE <WHERE@WHEREVER.COM>',
                               To      => 'YOUR_EMAIL_ADDRESS',
                               Subject => "$site Mason Website Error occured at $time",
                               Data    => $body,
                             );
    $msg->send('smtp','YOUR_SMTP_SERVER');
}

while (my $cgi = new CGI::Fast) {
    # the whole point of fastcgi requires the env to get reset here..
    # So we must squash it again (This was copied from RT's Fast CGI handler)
    $ENV{'PATH'}   = '/bin:/usr/bin';
    $ENV{'CDPATH'} = '' if defined $ENV{'CDPATH'};
    $ENV{'SHELL'}  = '/bin/sh' if defined $ENV{'SHELL'};
    $ENV{'ENV'}    = '' if defined $ENV{'ENV'};
    $ENV{'IFS'}    = '' if defined $ENV{'IFS'};

    # The Mason $r->uri includes the script name unless we do this
    $ENV{'SCRIPT_NAME'} = '';

    # This deals with someone entering yoursite.com/ to make sure it serves index.html
    if ( ( !$h->interp->comp_exists( $cgi->path_info ) )
        && ( $h->interp->comp_exists( $cgi->path_info . "index.html" ) ) ) {
        $cgi->path_info( $cgi->path_info . "index.html" );
    }
    #$cgi->header(-charset=>'utf-8');  # If your site uses utf-8 characters

    # Ping our db handle
    $HTML::Mason::Commands::Schema->ping;

    # Lets try and handle this...
    eval {
        $h->handle_cgi_object($cgi);
    };

    # Something happened, if it couldn't find the component, don't fatal
    # we'll re-process as a 404
    if ($@) {
        if ($@ =~ /could not find component/) {
            # If you want Mason to handle the error so you can keep your site appearence,
            # this will call Mason to display your error page. If the error was in the
            # code that is called on every page, this will cause trouble.
            $cgi->path_info('/errordocs/404.html');
            $h->handle_cgi_object($cgi);
        } else {
            send_email($@,$cgi);
        }
    }
}

# Tell FastCGI to put its temporary files somewhere sane.
FastCgiIpcDir /tmp

# Increases processes if you have heavy loads to deal with
FastCgiServer /usr/local/www/GroovieWebapp/mason-handler.fcgi -idle-timeout 120 -processes 2 

<VirtualHost *:80>
    ServerAdmin webmaster@YOUR_SERVER
    ServerName YOUR_SERVER_NAME

    AddHandler fastcgi-script fcgi
    ScriptAliasMatch (.*\.html$) /usr/local/www/GroovieWebapp/mason-handler.fcgi$1
    ScriptAliasMatch (.*\/$) /usr/local/www/GroovieWebapp/mason-handler.fcgi$1

    DocumentRoot /usr/local/www/GroovieWebapp
</VirtualHost>

Enjoy!*

% if ($form_status eq 'errors') {
<&| /lib/error_fill.mas, errors => $errors_hash_ref &>
<p style="color: red; font-weight:bold;">Errors Found: Please correct the fields indicated.
<& /forms/myform.mas, %ARGS &>
</&>
% } else {
<& /forms/myform.mas, %ARGS &>
% }

$errors_hash_ref is a hash ref that is keyed by the form field name, with the value set to the error message you want displayed. Right now, error_fill.mas does not have custom pre/post-fix variables for you to tweak how the error message is inserted. It currently puts a <br> followed by a red span element containing your message.

myform.mas is the form I want to display, I prefer to split sections out in Mason to keep my web application modular and the sections of my pages more reusable.

<%args>
$errors
</%args>
<%init>
# $errors is a hash reference keyed as:
#     'field name' > 'Error message'
use HTML::Parser;
my $form = $m->content;

my $p = HTML::Parser->new(api_version > 3);
$p->handler(default => sub { print @_ }, "text");
$p->handler(end => sub {
              my ($tagname, $text, $attr) = @_;
              if (($tagname eq 'select') && (exists $errors->{$attr->{name}})) {
                print $text;
                print '<span style="color:red;">';
                foreach my $err (@{$errors->{$attr->{name}}}) {
                  print '<br />'.$err;
                }
                print '</span>';

              } else {
                print $text;
              }
            },
            "tagname, text, attr");
$p->handler(start => sub {
              my ($tagname, $text, $attr) = @_;
              if (($tagname eq 'input') && (exists $errors->{$attr->{name}})) {
                print $text;
                print '<span style="color:red;">';
                foreach my $err (@{$errors->{$attr->{name}}}) {
                  print '<br />'.$err;
                }
                print '</span>';

              } else {
                print $text;
              }
            },
            "tagname, text, attr");
$p->parse($form);
</%init>