view release on metacpan or  search on metacpan

lib/Application/Pipeline.pm  view on Meta::CPAN

package Application::Pipeline;
$VERSION = '0.1';

=head1 Application::Pipeline

Application::Pipeline is a module designed to map methods ( referred to in this
role as handlers ) to different phases of an application's life cycle.
By assigning methods to different phases of this pipeline, the author can
concentrate on the logic for each phase and let the framework manage the
application flow.  Adopting the same idea as CGI::Application, writing an
application with Application::Pipeline is a matter of creating a module that is
a subclass of Application::Pipeline.

=head2 The %plan

To build a pipeline application, it is necessary to register methods to run
during each phase.  This can be done one at a time, with the C<addHandler>
method.  But Application::Pipeline also looks in the subclass package for the
package variable C<%plan>.  This hash's keys are the names of the phases of the
pipeline. Each key points to an array reference which is a list of the methods
to run for that phase.  The methods are either the names of the methods to run,
or references to the actual methods.

This is not the be-all end-all definition of the pipeline.  It is still possible
to use C<addHandler> to modify the pipeline, and as explained later, it is
possible to take into account C<%plan>s defined in superclasses.

=cut

#-- pragmas ---------------------------- 
 use strict;
 use warnings;

#-- modules ---------------------------- 
 use Symbol qw( gensym );

#-- package variables ------------------ 

our @phase_stages = qw( FIRST EARLY MIDDLE LATE LAST );

#===============================================================================

=head2 Running an Application::Pipeline Application

Application::Pipeline is an object oriented module, but has no constructor.  It
is intended to be used as a base class only.  The primary responsibility of
a constructor under Application::Pipeline is to specify an ordered list of
names for the phases of the pipeline.  As it would be impractical to come up
with one unified set of phases that suited every kind of application that
Application::Pipeline could drive, that task, and the constructor along with it,
is left to subclasses.

It is expected that there may eventually become a set of first-level subclasses
that define common sets of phases for different problem spaces.  This way
plugins that are suited to those domains may expect to find a predictable set of
phases when included.  For an initial example of one such subclass, see
WWW::Pipeline.

=head3 run

 $pipeline->run()

A script calls this method when it is ready to run the application.  There are
no parameters

=cut

sub run {
  my $self = shift;

  $self->_buildPlan();

  foreach my $phase ( @{$self->{_phases}} ) {
      foreach my  $stage ( @phase_stages ) {

          next unless defined $self->{_plan}{$phase}{$stage}
            and scalar @{$self->{_plan}{$phase}{$stage}};