CGI::Application::Plugin::FormState 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::PlugUserFContributed PCGI::Application::Plugin::FormState(3)

NAME
       CGI::Application::Plugin::FormState - Store Form State without Hidden
       Fields

VERSION
       Version 0.12

SYNOPSIS
       FormState is just a temporary stash that you can use for storing and
       retrieving private parameters in your multi-page form.

	   use CGI::Application::Plugin::FormState;

	   my $form = <<EOF;
	      <form action="app.cgi">
	      <input type="hidden" name="run_mode" value="form_process_runmode">
	      <input type="hidden" name="cap_form_state" value="<tmpl_var cap_form_state>">
	      ...
	      </form>
	   EOF

	   sub form_display_runmode {
	       my $self = shift;

	       # Store some parameters
	       $self->form_state->param('name'	     => 'Road Runner');
	       $self->form_state->param('occupation' => 'Having Fun');

	       my $t = $self->load_tmpl(scalarref => \$form);
	       return $t->output;

	   }

	   sub form_process_runmode {
	       my $self = shift;

	       # Retrieve some parameters
	       print $self->form_state->param('name');	     # 'Road Runner'
	       print $self->form_state->param('occupation'); # 'Having Fun'
	   }

EXAMPLE
       This is a more complete example, using
       CGI::Application::Plugin::ValidateRM.

	   use CGI::Application::Plugin::Session;
	   use CGI::Application::Plugin::FormState;
	   use CGI::Application::Plugin::ValidateRM;

	   my $form = <<EOF;
	      <form action="app.cgi">
	      <input type="hidden" name="run_mode" value="my_form_process">
	      <input type="hidden" name="cap_form_state" value="<tmpl_var cap_form_state>">
	      ...
	      </form>
	   EOF

	   sub my_form_display {
	       my $self	    = shift;
	       my $errs	    = shift;
	       my $t	    = $self->load_tmpl(scalarref => \$form);

	       # Stash some data into it
	       $self->form_state->param('name'	     => 'Wile E. Coyote');
	       $self->form_state->param('occupation' => 'Mining Engineer');

	       # Normal ValidateRM error handling
	       $t->param($errs) if $errs;
	       return $t->output;
	   }

	   sub my_form_process {
	       my $self;

	       # Normal ValidateRM validation
	       my ($results, $err_page) = $self->check_rm('my_form_display','_my_form_profile');
	       return $err_page if $err_page;

	       # The data from the submitted form
	       my $params = $self->dfv_results;

	       $params->{'name'}       = $self->form_state->param('name');	 # 'Wile E. Coyote'
	       $params->{'occupation'} = $self->form_state->param('occupation'); # 'Mining Engineer'

	       # Now do something interesting with $params
	       # ...

	       my $t = $self->load_tmpl('success.html');
	       return $t->output;
	   }

	   # Standard ValiateRM profile
	   sub _my_form_profile {
	       return {
		   required => 'email',
		   msgs => {
			   any_errors => 'some_errors',
			   prefix => 'err_',
		   },
	       };
	   }

DESCRIPTION
       "CGI::Application::Plugin::FormState" provides a temporary storage area
       within the user's session for storing form-related data.

       The main use of this is for multi-page forms.  Instead of using hidden
       fields to store data related to the form, you store and retrieve values
       from the form state.

       In the first instance of your app:

	   $self->form_state->param('some_name' => 'some_value');
	   $self->form_state->param('some_other_name' => 'some_other_value');

       And later, in a different instance of your app:

	   $val1 = $self->form_state->param('some_name');
	   $val2 = $self->form_state->param('some_other_name');

       To connect the first instance and the second, you put a single hidden
       field in your template:

	   <input type="hidden" name="cap_form_state" value="<tmpl_var my_storage_name>">

       You don't have to worry about creating the template param
       "cap_form_state"; it is added automatically to your template parameters
       via the "load_tmpl" hook.

       If you want to use a parameter other than "cap_form_state" you can do
       so via the "name" parameter to "form_state-"config>.

       If you're skeptical about whether all this abstraction is a good idea,
       see "MOTIVATION", below.

PRESERVING FORM STATE ACROSS REDIRECTS
       You can include the form_state hash in a link:

	   my $link = '/app.cgi?rm=list&cap_form_state=' . $self->form_state->id;

       If you use CGI::Application::Plugin::Redirect, you can easily create
       redirect this way:

	   $self->redirect('/app.cgi?rm=list&cap_form_state=' . $self->form_state->id);

       If you also use CGI::Application::Plugin::LinkIntegrity it is as simple
       as:

	   $self->redirect($self->link('/app.cgi', 'rm' => 'list', 'cap_form_state' => $self->form_state->id));

       Or, in the case of a link to the currently running app:

	   $self->redirect($self->self_link('rm' => 'list', 'cap_form_state' => $self->form_state->id));

IMPLEMENTATION
       When you call "$self->form_state" for the first time, a top-level key
       is created in the user's session.  This key contains a random, hard-to-
       guess element.  It might look something like:

	  form_state_cap_form_state_84eb13cfed01764d9c401219faa56d53

       All data you place in the form state with "param" is stored in the
       user's session under this key.

       You pass the name of this key on to the next instance of your
       application by means of a hidden field in your form:

	   <input type="hidden" name="cap_form_state" value="<tmpl_var cap_form_state>">

       You manually put this hidden field in your template.  The template
       parameter "cap_form_state" is automatically added to your template
       parameters via the "load_tmpl" hook.  It contains the random, hard-to-
       guess portion (e.g. "84eb13cfed01764d9c401219faa56d53").	 When the
       template is filled, the hidden field will look something like this:

	   <input type="hidden" name="cap_form_state" value="84eb13cfed01764d9c401219faa56d53">

       Since all values are stored on the server in the user's session, the
       user can't tamper with any of them.

       To keep old form_data from cluttering up the user's session, the system
       uses CGI::Session's "expire" feature to expire old form state keys
       after a reasonable amount of time has passed (2 days by default).

       You can manually delete a form state storage by calling:

	   $self->form_state->delete;

METHODS
       config(%options)
	   Sets defaults for the plugin.

	   Calling config is purely optional, since the defaults should be
	   fine most purposes.

	       $self->form_state->config('name' => 'storage_names', 'expires' => '3d')

	   The following options are allowed:

	   name
	       Sets the name of the default form state storage.	 This name is
	       used for the key in the user's session, for the name of hidden
	       form field, and the template parameter used to fill the hidden
	       form field.  So if you set the "name" to "foo":

		   $self->form_state_config('name' => 'foo');

	       then the hidden field in your template should look like this:

		   <input type="hidden" name="foo" value="<tmpl_var foo>">

	       and the key in the user's session would look something like
	       this:

		  form_state_foo_84eb13cfed01764d9c401219faa56d53

	   expires
	       Indicates when form state storage keys should expire and
	       disappear from the user's session.  Uses the same format as
	       CGI::Session's "expire".	 Defaults to 2 days ('2d').  To cancel
	       expiration and make the form state last as long as the user's
	       session does, use:

		   $self->form_state_config('expires' => 0);

       param
	   Read and set values in the form state storage.  It acts like the
	   "param" method typically does in modules such as CGI,
	   CGI::Application, CGI::Session, "HTML::Template" etc.

	       # set a value
	       $self->form_state->param('some_name' => 'some_value');

	       # retrieve a value
	       my $val = $self->form_state->param('some_name');

	       # set multiple values
	       $self->form_state->param(
		   'some_name'	     => 'some_value',
		   'some_other_name' => 'some_other_value',
	       );

	       # retrive the names of all the keys
	       my @keys = $self->form_state->param;

       clear_params
	   Clear all of the values in the form state storage:

	      $self->form_state->param('name' => 'Road Runner');
	      $self->form_state->clear_params;
	      print $self->form_state->param('name'); # undef

       delete
	   Deletes the form_state storage from the user's session.

       id  Returns the current value of the storage param - the "hard to
	   guess" portion of the session key.

	       my $id = $self->form_state->id;

       name
	   Returns the current name being used for storage.  Defaults to
	   "cap_form_state".

	       my $name = $self->form_state->name;

       session_key
	   Returns the full key used for storage in the user's session.

	       my $key = $self->form_state->session_key;

	       # Get the full form state hash
	       my $data = $self->session->param($key);

	   The following can be used to debug the form_state data:

	       use Data::Dumper;
	       print STDERR Dumper $self->session->param($self->form_state->session_key);

MOTIVATION
   Why not just use hidden fields?
       Hidden fields are not secure.  The end user could save a local copy of
       your form, change the hidden fields and tamper with your app's form
       state.

   Why not just use the user's session?
       With "CGI::Application::Plugin::FormState" the data is associated with
       a particular instance of a form, not with the user.  If the user gives
       up halfway through your multi-page form, you don't want their session
       to be cluttered up with the incomplete form state data.

       If a user opens up your application in two browser windows (both
       sharing the same user session), each window should have it's own
       independent form state.

       For instance, in an email application the user might have one window
       open for the inbox and another open for the outbox.  If you store the
       value of "current_mailbox" in the user's session, then one of these
       windows will go to the wrong mailbox.

       Finally, the user's session probably sticks around longer than the form
       state should.

AUTHOR
       Michael Graham, "<mag-perl@occamstoothbrush.com>"

BUGS
       Please report any bugs or feature requests to
       "bug-cgi-application-plugin-formstate@rt.cpan.org", or through the web
       interface at <http://rt.cpan.org>.  I will be notified, and then you'll
       automatically be notified of progress on your bug as I make changes.

ACKNOWLEDGEMENTS
       Thanks to Richard Dice and Cees Hek for helping me sort out the issues
       with this approach.

       The informative error message text used for when this module is loaded
       before your app actually @ISA "CGI::Application" object was stolen from
       Cees's CGI::Application::Plugin::TT module.

COPYRIGHT & LICENSE
       Copyright 2005 Michael Graham, 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			  2011-0CGI::Application::Plugin::FormState(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