NAME CGI::Application::Plugin::FormState - Store Form State without Hidden Fields VERSION Version 0.01 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 sub form_display_runmode { my $self = shift; $self->form_state->init('some_storage_name'); # 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; $self->form_state->init('some_storage_name'); # 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 sub my_form_display { my $self = shift; my $errs = shift; my $t = $self->load_tmpl(scalarref => \$form); # Initialize the form state $self->form_state->init('myform_data'); # 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; # Now merge the additional data that we stored in the Form State $self->form_state->init('myform_data'); $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->init('my_storage_name'); $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: $self->form_state->init('my_storage_name'); $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: You don't have to worry about creating the template param "my_storage_name"; it is added automatically to your template parameters via the "load_tmpl" hook. Just make sure that the hidden field name and template parameter name both match the form state storage name, as passed to "init". If you're skeptical about whether all this abstraction is a good idea, see "MOTIVATION", below. IMPLEMENTATION When you call "$self->form_state->init" for the first time, a top-level key is created in the user's session. This key contains a random, hard-to-guess element. If your storage name is called 'my_data', it might look something like: form_state_my_data_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: You manually put this hidden field in your template. The template parameter "my_data" 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: In the application that receives this form submission, when you call "$self->form_state->init('my_data')", the form state is initialized from the pre-existing key in the user's session. 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 (1 day by default). METHODS init('storage_name', %options) Initializes the form state storage, using the name "storage_name". If a query parameter named "storage_name" already exists, then the form state of that name is restored from the user's session. If a query parameter named "storage_name" does not exist, then a storage for the form state of that name is created in the user's session. To connect the app writing the form state with the app reading it, you need to add a hidden field to your form: (Although you do not have to add the template parameter "storage_name"; it is added automatically) Named options follow the "storage_name": $self->form_state->init('storage_name', expires => '2d'); The following option is currently available: expires Indicates when this form state storage should expire and disappear from the user's session. Uses the same format as CGI::Session's "expire". Defaults to 1 day ('1d'). To cancel expiration and make the form state last as long as the user's session does, use: $self->form_state->init('storage_name', 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 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, "" BUGS Please report any bugs or feature requests to "bug-cgi-application-plugin-formstate@rt.cpan.org", or through the web interface at . 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. 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.