Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

Life, Love and CGI::Application::Plugin::ValidateRM (and Friends)

by novastorm0 (Beadle)
on Nov 07, 2008 at 14:57 UTC ( [id://722232]=perlquestion: print w/replies, xml ) Need Help??

novastorm0 has asked for the wisdom of the Perl Monks concerning the following question:

After searching both google and perlmonk's I've come up pretty light on results concerning my dilemma. Now when you use CGI::Application::Plugin::ValidateRM there are several ways to implement this. You can have what I would call a 3 method system. The first method to display the form, another to process the form, and lastly one for your form's profile. I've also seen it implemented in one runmode. Is there a best practice to this? Are you better off storing your profile in a variable then its own method? Does this even matter (in the scope of scalability/memory usage) Is mod_perl a factor?

To start I'm using strict, warnings, apache, mod_perl, and taint mode. So I have a list of users, then actions (url driven). I.E. user1 edit myapp.pl?rm=edit&user=1. Etc you get the point. So you click and the edit runmode goes off without a hitch, and it understands that your editing user 1. Now in the template that displays edit comes lots of the "best practices" part of my question. So to make this more clear we have display_form and process_form (from the doc example). The display_form presents the form and has a hidden field name=rm value=process_form for the runmode to process that form. Now the behavior of this is interesting because it more or less keeps the magic hidden from the user (from the url bar its not evident that your using a different runmode, at least for me), or you can method=post action=?rm=process_form which breaks up the url and makes it evident your using a new runmode.

Now my second problem is that regardless of how hard I try I cannot get that initial user query,variable whatever to be persistent between methods. Making a Query object and trying to $q->param('user') or die; in process_form dies with a particularly useless error message. Shoving $q->param('user') into $myapp->param('user') in the display_form method fails to hand off in process_form. In all the examples the query data is happily persistent between methods/runmodes, a behavior that I can't seem to replicate. Now you may say to use sessions, fine, then my question to you is "I'm using CGI::Application::Plugin::Authentication which uses a session to check if your logged in, do I create another?" I haven’t been able to access the CGI::Application::Plugin::Authentication generated session yet, but I could just make another but I figured that its somehow sloppy to create two sessions for one user.

Now I understand that there is not always a "right" way to do things, but there is a secure way of doing this and a fast way of doing things. So I seek the advice of those wiser then I to advise me on my problem and thanks for reading the tome.

Replies are listed 'Best First'.
Re: Life, Love and CGI::Application::Plugin::ValidateRM (and Friends)
by rhesa (Vicar) on Nov 09, 2008 at 08:55 UTC
    Lots of questions here!

    First off, remember that HTTP is a stateless protocol, which means that the server(s) do not share any data between requests. You need to do that explicitly, either by putting data in the url, or in a form, or in a session.

    Sharing state between requests

    You have essentially three options:
    1. Using url parameters: myapp?rm=edit;user=1 produces a page, and adds user=1 to the relevant urls. E.g. myapp?rm=save;user=1. The next request finds the user id with $self->query->param('user').
    2. Using form fields: The same request produces a form with a hidden field:
      <form action="myapp"> <input type="hidden" name="rm" value="save"> <input type="hidden" name="user" value="1">
      The next request finds the user id with $self->query->param('user') as well.
    3. using a session: The same request creates a session, stores user=>1 in it, and sends a cookie with the session id in it along with the output. The next request looks in the session for the "user" parameter.

    How to use sessions with CGI::Application

    Save yourself headaches, and install CGI::Application::Plugin::Session. Configuration is pretty straightforward. Usage is dead simple too:
    sub edit { my $self = shift; my $user_id = $self->query->param( 'user' ); $self->session->param( user => $user_id ); # store it ... } sub save { my $self = shift; my $user_id = $self->session->param( 'user' ); # retrieve it ... }

    Form validation strategy

    It's handy to have form display and form processing in separate methods. The general pattern of form processing is
    1. Gather input
    2. Validate input
      • If invalid, display the form again with error messages
      • If valid, process the input
    Something like this:
    sub display_form { ... } sub process_form { my $self = shift; my @input = data_from_query_or_session(); # use CAP::ValidateRM here my @errors = validate( $profile, @input ); if( @errors ) { # HTML::FillInForm makes this easier return $self->display_form( @errors ); } # submission was ok, process the data ... }
    Hope that helps :)

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://722232]
Approved by marto
Front-paged by planetscape
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others goofing around in the Monastery: (3)
As of 2024-03-19 05:02 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found