Maypole::Manual::Request 2.09

Maypole::Manual::Request is a Maypole Request Hacking Cookbook.

Hacks; design patterns; recipes: call it what you like, this chapter is a developing collection of techniques which can be slotted in to Maypole applications to solve common problems or make the development process easier.

As Maypole developers, we don't necessarily know the "best practice" for developing Maypole applications ourselves, in the same way that Larry Wall didn't know all about the best Perl programming style as soon as he wrote Perl. These techniques are what we're using at the moment, but they may be refined, modularized, or rendered irrelevant over time. But they've certainly saved us a bunch of hours work.

Frontend hacks

These hacks deal with changing the way Maypole relates to the outside world; alternate front-ends to the Apache and CGI interfaces, or subclassing chunks of the front-end modules to alter Maypole's behaviour in particular ways.

Separate model class modules

You want to put all the BeerDB::Beer routines in a separate module, so you say:

package BeerDB::Beer;
BeerDB::Beer->has_a(brewery => "BeerDB::Brewery");
sub foo :Exported {}

And in BeerDB.pm, you put:

use BeerDB::Beer;

It doesn't work.

Solution: It doesn't work because of the timing of the module loading. use BeerDB::Beer will try to set up the has_a relationships at compile time, when the database tables haven't even been set up, since they're set up by

BeerDB->setup("...")

which does its stuff at runtime. There are two ways around this; you can either move the setup call to compile time, like so:

BEGIN { BeerDB->setup("...") }

or move the module loading to run-time (my preferred solution):

BeerDB->setup("...");
BeerDB::Beer->require;

Requirements:

· Perl



Product's homepage