Maypole::CLI(3)

💖 Maypole::CLI — the vibe-coded way to poke at your Maypole site 💖

okay so bestie, this is the Maypole::CLI page from the User Contributed Perl Documentation, and it's genuinely iconic. It's the command line interface to Maypole, for testing and debugging. No web server, no CGI frontend nonsense, just you, your terminal, and the truth. ✨

---

🌸 NAME 🌸

Maypole::CLI — command line interface to Maypole for testing and debugging 🎀

---

✨ SYNOPSIS ✨

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

that's literally it. two lines. slay. 💅

---

🦋 DESCRIPTION 🦋

so here's the tea: this module lets you test Maypole sites without going through a web server, and without having to modify them to use a CGI frontend. main character energy, honestly.

Before you use it, you need to do one of two things first:

• be chilling in the template root for your Maypole site already, or
• set the environment variable MAYPOLE_TEMPLATES to the right value.

Then you import the Maypole::CLI module and specify your base Maypole subclass. The usual way is with the -M flag: perl -MMaypole::CLI=MyApp. And that's exactly the same as writing:

    use Maypole::CLI qw(MyApp);

Now Maypole will automatically call your application's handler with the URL you passed as the first command line parameter. That URL should be the full URL, starting from whatever you defined as the uri_base in your application's configuration, and it may include query parameters. Go off, query strings. 🫶

And then? The Maypole HTML output ends up on standard output. Like magic, but it's Perl. 😭

---

🧪 Support for testing 🧪

The module can also be used as part of a test script. It's giving double life. 💖

When you use it programmatically, rather than from the command line, its behaviour is slightly different — like, same girl, different font.

So here's the deal:

• The URL is still taken from @ARGV as normal, no change there.
• But your application's handler method is NOT called automatically, the way it is on the command line. You have to call it manually, bestie.
• Also, when handler is called, the output is not printed to standard output — instead it gets stored in $Maypole::CLI::buffer, so you can check the contents way 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");

not the # Hack because isa_ok only supports object isa not class isa comment living in the code fr fr 💀 we respect the honesty.

---

🔥 METHODS 🔥

• call_url — for use in scripts. It takes an url as argument, and returns the buffer. that's it, that's the method. short queen. 👑

---

🧚 Implementation 🧚

This class overrides a set of methods in the base Maypole class to provide it's functionality. See Maypole for these:

• get_template_root
• parse_args
• parse_location
• send_output
• warn

five overrides, no notes, periodt. 🌈

---

ok quick vibe check: don't forget that MAYPOLE_TEMPLATES thing or that you gotta be in the template root, or the whole thing simply won't hit. no cap. 💜

---

and that's the whole page, bestie!! this was Maypole::CLI(3) from the User Contributed Perl Documentation, and the footer energy is giving perl v5.42.0 dated 2025-07-25. stay slaying, stay testing, and remember: the buffer is your friend 🍓✨💖