>I've never used C::A (or C::P), but why must the runmode be in a hidden field? Why not have the submit button be the runmode value?
That's what I do in C::A. My POST url looks something like "/cgi-bin/profile?area=acc" to signify that the form is submitted to the "profile" script, and is intended to access the sub-page "account settings." I suppose "area" is a run-mode. But, I go further, using the submit button's value to internally choose a runmode.
My C::A code looks something like
if (defined($q->param('area'))) {
if ($q->param('area') eq 'acc') {
if (defined($q->param('change_psw'))) {
$self->start_mode('21');
} # end form to change password was submitted
elsif (defined($q->param('change_acc'))) {
$self->start_mode('22');
} # end form to change account settings was submitted
elsif (defined($q->param('send_verify'))) {
$self->start_mode('23');
} # end form to verify email address was submitted
else {
$self->start_mode('2');
} # end there was no submit, profile-account page should be displa
+yed
} # end profile area = account
else {
$self->start_mode('1');
} # end no profiel area was provided, profile main page should be disp
+layed
The idea here is that the "area" takes me to a specific sub-page for "profile" (account settings, my personal info, description, photos). If area is not set (or unintelligible), the main profile page is displayed (as if it's an initial display).
If an area is specified, then if submit buttons (there may be more than one form on a page) set the run mode to process whichever was pressed. If no submit button was pressed, it's an initial display of the page (for that area).
It works well for me. It gets ugly with long nested if/elsif structures. Followed by a long self->run_mode hash associating the numeric codes to the subroutines.
I can see that CGI::Prototyle could make this more natural through inheritance. But, I like being able to see all the details and understanding how it works. OO is elegant but I still have trouble thinking in those terms.
Mark