NAME
    CGI::Application::Plugin::MessageStack - A message stack for your
    CGI::Application

VERSION
    Version 0.12

SYNOPSIS
    This plugin gives you a few support methods that you can call within
    your cgiapp to pass along messages between requests for a given user.

     use CGI::Application::Plugin::Session;
     use CGI::Application::Plugin::MessageStack;

     sub mainpage {
       my $self = shift;
       my $template = $self->load_tmpl( 'mainpage.TMPL', 'die_on_bad_params' => 0 );
       # ...
       $template->output;
     }

     sub process {
       my $self = shift;
       $self->push_message(
           -scope          => 'mainpage',
           -message        => 'Your listing has been updated',
           -classification => 'INFO',
         );
       $self->forward( 'mainpage' );
     }

     sub cgiapp_init {
       # setup your session object as usual...
     }

    Meanwhile, in your (HTML::Template) template code:

     ...
     <style type="text/css">
       .INFO {
         font-weight: bold;
       }
       .ERROR {
         color: red;
       }
     </style>
     ...
     <h1>Howdy!</h1>
     <!-- TMPL_LOOP NAME="__CAP_Messages" -->
       <div class="<!-- TMPL_VAR NAME="classification" -->">
         <!-- TMPL_VAR NAME="message" -->
       </div>
     <!-- /TMPL_LOOP -->
     ...

    It's a good idea to turn off 'die_on_bad_params' in HTML::Template - in
    case this plugin tries to put in the parameters and they're not
    available in your template.

    I had to make a special case for TT, since it doesn't support variable
    names that start with an underscore. So for you TT folks, use
    "CAP_Messages" instead. Here's a quick example:

    Here's a quick TT example:

     <style type="text/css">
       .INFO {
         font-weight: bold;
       }
       .ERROR {
         color: red;
       }
     </style>
     ...
     <h1>Howdy!</h1>
     [% FOREACH CAP_Messages %]
        <div class="[% classification %]">[% message %]</div>
     [% END %]
     ...

    If you use TT, I recommend using CAP-TT and a more recent version
    (0.09), which supports cgiapp's load_tmpl hook and then this plugin will
    automatically supply TT with the relevant messages. Your runmode could
    be this simple:

     sub start {
         my $self = shift;
         my $session = $self->session;
         return $self->tt_process( 'output.tt' );
     }

    I don't have the experience to weigh in on how you'd do this with other
    templates (HTDot, Petal), but basically, this plugin will put in a loop
    parameter called '__CAP_Messages'. Within each element of that loop,
    you'll have two tags, 'classification' and 'message'.

    Note: I'm considering changing the loop's variable name (for the non-TT
    folks), just so I don't have to make a special branch in my callback
    code. I may just live with it, but I'm just not saavy on using cgiapp's
    internal "__TT_OBJECT" variable.

DESCRIPTION
    This plugin *NEEDS* a session object to tuck away the message(s). So
    please use this in conjunction with CGI::Application::Plugin::Session.

    This plugin hooks into cgiapp's load_tmpl method and if you've pushed
    any messages in the stack, will automatically add the message
    parameters.

    In the functions, there are scope & classification keys and when they're
    used for either display or your API purposes (clearing, pop'ing, etc),
    the classification is an exclusive specification. Meaning, if you ask
    for messages with the 'ERROR' classification, it will only deal with
    messages that you've pushed in with the 'ERROR' classification. Any
    messages that have no classification aren't included.

    The scope key is not exclusive, meaning that if you ask for messages
    with a 'mainpage' scope, it will deal with messages that you've pushed
    with that scope as well as any messages that you've pushed in without a
    scope.

    If you use both scope & classification, it blends both of those rules,
    first getting all matching messages with the same classification and
    then filtering out messages that are scoped and don't match the scope
    you're looking for.

    This logic may change as I get feedback from more saavy developers. What
    we may end up doing is have a plugin configuration where you can dictate
    the logic that's used.

FUNCTIONS
  push_message
     $self->push_message(
         -scope          => 'mainpage',
         -message        => 'Your listing has been updated',
         -classification => 'INFO',
       );

    You provide a hash to the push_message() method with three possible
    keys:

    * message - a text message. You can put HTML in there - just make sure
    you don't use the ESCAPE=HTML in your HTML::Template code
    * scope - which runmode(s) can this message appear? If you want to
    specify just one, use a scalar assignment. Otherwise, use an array
    reference with the list of runmodes.
    * classification - a simple scalar name representing the classification
    of your message (i.e. 'ERROR', 'WARNING' ... ). This is very useful for
    CSS styles (see template example above).

    The scope & classification keys are optional. If you don't provide a
    scope, it will assume a global presence.

  messages
     my @messages = $self->messages();
     my @messages = $self->messages( -scope => 'mainpage' );
     my @messages = $self->messages( -scope => 'mainpage', -classification => 'ERROR' );
     my @messages = $self->messages( -classification => 'ERROR' );

    If you want to take a gander at the message stack data structure, you
    can use this method.

    Optionally, you can use a hash parameters to get a slice of the
    messages, using the same keys as specified in the push_message() method.

    It will return an array reference of the matching messages or 'undef',
    if there's either no messages in the stack or no messages that match
    your specification(s).

  pop_message
     my $message = $self->pop_message();
     my $message = $self->pop_message( -scope => 'mainpage' );
     my $message = $self->pop_message( -scope => 'mainpage', -classification => 'WARNING' );
     my $message = $self->pop_message( -classification => 'ERROR' );

    Pops off the last message from the stack and returns it. Note that this
    just returns the -message part.

    You can pop off an exact message, given a hash parameters, using the
    same keys as specified in the push_message() method.

    Otherwise, it will pop off the message, given the current runmode and
    the last message added.

  clear_messages
     $self->clear_messages();
     $self->clear_messages( -scope => 'mainpage' );
     $self->clear_messages( -scope => 'mainpage', -classification => 'ERROR' );
     $self->clear_messages( -classification => 'ERROR' );

    Clears the message stack.

    Optionally, you can clear particular slices of the message stack, given
    a hash parameters, using the same keys as specified in the
    push_message() method.

    If you specify a scope, it will clear any messages that are either
    global or match that scope

    If you specify a classification, it will clear any messages that have
    that classification (but not any messages that don't have any
    classification).

    If you specify both, it will combine both that logic in an AND fashion.

AUTHOR
    Jason Purdy, "<Jason@Purdy.INFO>"

TODO
    Got some great feedback from the usual suspects, so I'm looking to work
    on this stuff for future versions - mostly a config type of system:

    * Optional Session Integration - Allow a developer to specify that
    messages are not to be stored in the session.
    * Optional Automatic Message Clearing - Right now, clear_messages() has
    to be called manually. How about doing it automatically, if the
    developer would like?
    * Configuration of template parameter names - allow the developer to
    dictate what the parameter names are for the loop and the
    classification/message.

SEE ALSO
    CGI::Application and CGI::Application::Plugin::Session

BUGS
    Please report any bugs or feature requests to
    "bug-cgi-application-plugin-messagestack@rt.cpan.org", or through the
    web interface at
    <http://rt.cpan.org/NoAuth/ReportBug.html?Queue=CGI-Application-Plugin-M
    essageStack>. I will be notified, and then you'll automatically be
    notified of progress on your bug as I make changes.

    I suspect that this code could use some expert guidance. I hacked it
    together and I'd hate to think that it would be responsible for slowing
    templates down. Please feel free to submit patches, guiding comments,
    etc.

ACKNOWLEDGEMENTS
    Thanks to the guys on the #cgiapp channel

COPYRIGHT & LICENSE
    Copyright 2005 Jason Purdy, all rights reserved.

    This program is free software; you can redistribute it and/or modify it
    under the same terms as Perl itself.