view release on metacpan or  search on metacpan

README  view on Meta::CPAN

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

VERSION
    Version 0.34

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.

    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 have broken backwards compatibility with this release (0.30) and
    the loop parameter's default name is now 'CAP_Messages'. If you used the
    old __CAP_Messages or want to use another name, feel free to use the
    capms_config to override the "-loop_param_name".

DESCRIPTION
    This plugin by default needs a session object to tuck away the
    message(s). It's recommended that you use this in conjunction with
    CGI::Application::Plugin::Session. You can opt to not have the messages
    persist and thereby, not use CAP-Session by using the
    "-dont_use_session" option in the "capms_config" method.

    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.