NAME

SYNOPSIS

  % setenv MAYPOLE_TEMPLATES /var/www/beerdb/
  % perl -MMaypole::CLI=BeerDB -e1 http://localhost/beerdb/brewery/frontpage

DESCRIPTION

Next, you import the "Maypole::CLI" module specifying your base Maypole subclass. The usual way to do this is with the "-M" flag: "perl -MMaypole::CLI=MyApp". This is equivalent to:

    use Maypole::CLI qw(MyApp);

Now Maypole will automatically call your application's handler with the URL specified as the first command line parameter. This should be the full URL, starting from whatever you have defined as the "uri_base" in your application's configuration, and may include query parameters.

The Maypole HTML output should then end up on standard output.

Support for testing

When used programmatically, rather than from the command line, its behaviour is slightly different.

Although the URL is taken from @ARGV as normal, your application's "handler" method is not called automatically, as it is when used on the command line; you need to call it manually. Additionally, when "handler" is called, the output is not printed to standard output but stored in $Maypole::CLI::buffer, to allow you to check the contents more easily.

For instance, a test script could look like this:

    use Test::More tests => 3;
    use Maypole::CLI qw(BeerDB);
    use Maypole::Constants;
    $ENV{MAYPOLE_TEMPLATES} = "t/templates";

    # Hack because isa_ok only supports object isa not class isa
    isa_ok( (bless {},"BeerDB") , "Maypole");

    like(BeerDB->call_url("http://localhost/beerdb/"), qr/frontpage/, "Got the front page");

    like(BeerDB->call_url("http://localhost/beerdb/beer/list"), qr/Organic Best/, "Found a beer in the list");

METHODS

call_url

for use in scripts. takes an url as argument, and returns the buffer.

Implementation

get_template_root

parse_args

parse_location

send_output

warn