CGI::Application::Plugin::MessageStack man page on Fedora

Man page or keyword search:  
man Server   31170 pages
apropos Keyword Search (all sections)
Output format
Fedora logo
[printable version]

CGI::Application::PlugUserMContributeCGI::Application::Plugin::MessageStack(3)

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.

       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.

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

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

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-MessageStack
       <http://rt.cpan.org/NoAuth/ReportBug.html?Queue=CGI-Application-Plugin-
       MessageStack>.  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.

perl v5.14.1			  201CGI::Application::Plugin::MessageStack(3)
[top]

List of man pages available for Fedora

Copyright (c) for man pages and the logo by the respective OS vendor.

For those who want to learn more, the polarhome community provides shell access and support.

[legal] [privacy] [GNU] [policy] [cookies] [netiquette] [sponsors] [FAQ]
Tweet
Polarhome, production since 1999.
Member of Polarhome portal.
Based on Fawad Halim's script.
....................................................................
Vote for polarhome
Free Shell Accounts :: the biggest list on the net