RFC: CAP::FormState - store form state without hidden fields

I'm working on a module called CGI::Application::Plugin::FormState.

The idea is that you use a temporary key in the user's session to store
form data instead of using hidden fields or using the user's session
directly.

The docs are done (I pasted them at the bottom of this message).  Tests
and code will follow in the next week or two.

In the meantime, I'm wondering if the module name might not be general
enough.  The obvious use of this concept is as a replacement for hidden
fields, but it could also be used for other temporary data that you want
to associate with a specific app instance (i.e. the browser window
rather than the user session.)

For instance, maybe it would be useful as a storage mechanism for Jason
Purdy's proposed MessageStack plugin:

    http://cgiapp.erlbaum.net/cgi-bin/cgi-app/index.cgi?MessageStack

If so, then maybe a more general name would be appropriate?  SubSession?
TempSession?

The problem with switching to a more general name is that it's hard
enough already to explain the purpose of this module as a replacement
for hidden fields.  If I remove this one concrete example it will be all
the more difficult to explain.

Anyway, the docs are below.  Comments welcome!


Michael



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

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="some_storage_name" value="<tmpl_var 
some_storage_name>">
           ...
           </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;
           <form action="app.cgi">
           <input type="hidden" name="run_mode" value="my_form_process">
           <input type="hidden" name="myform_data" value="<tmpl_var 
myform_data>">
           ...
           </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');

            $param{'name'}       = $self->form_state->param('name');       # 
'Wile E. Coyote'
            $param{'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:

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

    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:

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

    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").

    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:

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

        (Although you don't 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').

    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;

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@xxxxxxxxxxxxxxxxxxxx>"

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.


---
Michael Graham <magog@xxxxxxxxxxxx>


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/cgiapp@xxxxxxxxxxxxxxxxx/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: cgiapp-unsubscribe@xxxxxxxxxxxxxxxxx
For additional commands, e-mail: cgiapp-help@xxxxxxxxxxxxxxxxx