PET Explained

• Most of the time PET runs as a standalone server.  When a request hits your webserver, some of those requests - by default pages with extension .pet - are sent to the PET server (e.g. via a FastCGI socket).  Let’s say now that you get http: //www.example.com/test.pet
• The PET server checks if you have that .pet file (test.pet).  If there is one, we go on...
• If an MVC model is configured, PET calls the necessary modules associated with the file (e.g.  ACTION_test)
• Depending on the output of ACTION_tes, PET either redirects the call (HTTP-redirect), or we go on, and...
• If the template is not yet processed, and filters are configured, the template is run through the filters, and gets compiled
• The compiled template is fetches, and is “executed” (meaning it is run through TT - The Template Toolkit)

These are the basics.  To the user everything is transparent.  There are obviously many more things going on...

Note : you might skip the remaining part of this document at first read.

Wrappers

The main module of PET is PET::Dispatcher.  It calls everything else.  However, it assumes that it is run in a “CGI-like, persistent environment”, e.g. under FastCGI.  (It can also be run from CLI or even in CGI mode, but those are corner cases.)  Different kinds of “wrappers” are provided under <PET::RUN>, which interface PET::Dispatcher to your environment.

Init time

When started, PET::Dispatcher reads global.conf, its main configuration file, and sets up its internals : load modules, filters, defines database connections, and so on.  Then the PET server waits on incoming requests.  As PET is supposed to be run in a persistent environment, it is a good idea to load static data at this point.  More precisely:

• Filters, Mappers, Caches are set up
• Util classes are loaded and instanteniated
• API classes are loaded and instanteniated
• The logs are open
• Global.conf is fetched and stored

Request resolution

Your webserver is configured so that it sends certain incoming requests to PET.  Usually this simply means that any URL ending with “.pet” are sent to the PET server.  The extension can be overriden, e.g. to use “.asp” or whatnot.

Starting a request

When a request is received, the PET server begins a request.  It sets up environment variables (e.g. populates the $Form and $Query variables, initing the session, etc.)  Please note that everything in PET is configurable to make your life easier -- however, because of this, we can hardly say what PET does : it does what it is configured to do.

Serving a request

After initing everything, PET serves the request.

• Checks if the timestamp of your .pet file has changed.  If it did not, it simply fetches it from memory or from disk.
• If filters are configured, the template is first run through the filters in the order as they appear in global.conf.
• PET checks if there is an ActionMapper defined.  If there is, that actionmapper is called, giving back an closure which calls a method on an object alreadi initialized (at init time), provided by the user
• The actionmapper is called (if one is defined), and substitution variables are (can be) created by your application
• The .pet template (page) is processed using Template.pm, and the results are output

Under construction

• PET::Dispatcher
• PET::Run::*
• PET::Session::*
• PET::Util::*
• PET::Filter::*
• PET::APISkeleton::**
• PET::ActionMapper::**

Under construction