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.

capms_config

 $self->capms_config(
     -automatic_clearing            => 1,
     -dont_use_session              => 1,
     -loop_param_name               => 'MyOwnLoopName',
     -message_param_name            => 'MyOwnMessageName',
     -classification_param_name     => 'MyOwnClassificationName',
   );

There is a configuration option that you, as the developer can specify:

• -automatic_clearing: By default, this is turned off. If you override it with a true value, it will call clear_messages() automatically after the messages are automatically put into template.
• -dont_use_session: This will override this Plugin's dependence on CGI::Application::Plugin::Session and instead, temporarily store the message data such that it will be available to templates within the same web request, but no further. If you're running your cgiapp under a persistent state (mod_perl), we'll also make sure your messages are gone by the end of the request.
• -loop_param_name: This will override the default __CAP_Messages (or CAP_Messages for TT users) name for the loop of messages, which is only used for the "load_tmpl" callback. Meaning, this configuration will only impact your template code. So if you use the 'MyOwnLoopName' above, then your template code (for HTML::Template users) should look like:

   <!-- TMPL_LOOP NAME="MyOwnLoopName" -->
   ...
   <!-- /TMPL_LOOP -->
      

• -message_param_name: This will override the default '-message' in both the template code as well as the keys in each hashref of the arrayref that's returned by the messages() function. So a call to messages() may return:

   [ { 'MyOwnMessageName' => 'this is just a test' }, ... ]
      

  instead of:

   [ { '-message' => 'this is just a test' }, ... ]
      

  Likewise, your templates will need to use your parameter name:

   <!-- TMPL_LOOP NAME="MyOwnLoopName" -->
     Here's the message: <!-- TMPL_VAR NAME="MyOwnMessageName" -->
   <!-- /TMPL_LOOP -->
      

• -classification_param_name: Just like the "-message_param_name" parameter - this will override the default '-classification' key in both the template code as well as the keys in each hashref of the arrayref that's returned by the messages() function. So a call to messages() may return:

   [ { 'MyOwnClassificationName' => 'ERROR', 'MyOwnMessageName' => 'this is just a test' }, ... ]
      

  instead of:

   [ { '-classification' => 'ERROR', '-message' => 'this is just a test' }, ... ]
      

  Likewise, your templates will need to use your parameter name:

   <!-- TMPL_LOOP NAME="MyOwnLoopName" -->
      <div class="<!-- TMPL_VAR NAME="MyOwnClassificationName" -->">
         Here's the message: <!-- TMPL_VAR NAME="MyOwnMessageName" -->
      </div>
   <!-- /TMPL_LOOP -->