view release on metacpan or  search on metacpan

lib/CGI/Application/Plugin/MessageStack.pm  view on Meta::CPAN

=head1 VERSION

Version 0.34

=cut

use vars qw( @ISA $VERSION @EXPORT %config );

@ISA = qw( Exporter AutoLoader );

@EXPORT = qw(
    push_message
    pop_message
    clear_messages
    messages
    capms_config
);

sub import {
    my $caller = scalar( caller );
    $caller->add_callback( 'load_tmpl' => \&_pass_in_messages );
    goto &Exporter::import;
}

$VERSION = '0.34';

=head1 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'...

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 C<-lo...

=head1 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 us...

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' class...

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 B<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.

=head1 FUNCTIONS

=head2 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:

=over

=item * 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

=item * 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.

=item * 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).

=back