I would have the first button have a small Javascripty-doo that changes the hidden runmode field from ActuallySubmit to AddAnother, then submit.

dragonchild, 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? For example:

<form action="blah" method="post">
  <input type="text" name="data" value="Default data." />
  <input type="submit" name="runmode" value="Save" />
  <input type="submit" name="runmode" value="Add more data" />
</form>
[download]

If the "Save" button is clicked, the "Save" runmode will be called. If the "Add more data" button is clicked, that runmode will be called.

The only limitation is that either your button text or runmode names will be ugly.

It's not completely bad since you can have the same form submit to different run modes with the same data without having to do some javascript hacking, but it does have it's down side...

If you change the wording on the button (to be more user friendly, etc) then you also have to change the perl code on the backend to have that same name as the run-mode. not horribly difficult, but it means that a purely design change would need a change to the perl.

If you change the wording on the button (to be more user friendly, etc) then you also have to change the perl code on the backend to have that same name as the run-mode. not horribly difficult, but it means that a purely design change would need a change to the perl.

I use a custom run_mode that allows me to use the name of the button instead of the value which gets around this problem. It also allows the use of image buttons.

William

I've been doing that for quite some time. The CGI::Application concept of runmodes (state transitions) seems to work best if there is only one runmode the user can go to next. In my case, there are multiple buttons on the page, each of which needs to transition to a different runmode. So, in my CGI::Application::setup routine, I define a hash that shows the mapping of how to do the transitions. Transitions depend not only on the name of the submit button but a hidden parameter that holds the last runmode (e.g. where we came from) since different runmodes could use the same button name to do different things. For example, I might have this in my setup routine. Note, I find the term "runmode" non-intuitive so in my applications I use the term "state".

$self->mode_param(\&which_state);
$self->{DISPATCH_SUBMIT} = {
   'state_main' => {
      ' Create new question ' => 'state_new_question',
      ' View all questions ' => 'state_view_all',
   },
   'state_new_question' => {
      'Add question' => 'state_add_question',
      'Cancel'       => 'state_main',
   }
}
[download]

The first entry in the hash is the the state the user just came from. The next level in the hash is the name of the submit button and then what runmode subroutine to call. Then in my application, there's a method called which_state which looks at the last state and decides what to do next. If a runmode has only 1 possible transition, then it can set the runmode (state) value directly and bypass this mechanism. This has worked quite well for me. A possible downside is that the name of the submit button (which some might argue is content) is embedded in the code so a change to the page requires a change to the code. In my case, I manage both content and code so I have not been hindered by this.

the runmode is determined by a CGI parameter, usually named 'rm'. Because of that, it usually is a hidden input called 'rm' with the name of the next runmode as its value.

The Submit buttons sound like an interesting idea ... There are a few interesting quirks to it, but it looks like it could be made to work. ++!

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.

You get into namespace issues. It's easy to give two submit buttons the same value in your application that are supposed to go to different runmodes. In a large application, you'll probably run out of good names eventually.

I always felt that HTML using the "value" param on submit buttons was a bad design choice, and I think this illustrates that problem well. This, of course, is HTML's problem, not C::A's.

"There is no shame in being self-taught, only in not trying to learn in the first place." -- Atrus, Myst: The Book of D'ni.

>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
[download]

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

My POST url looks something like "/cgi-bin/profile?area=acc"

The last time I looked, CGI.pm required a code change to allow both POST and GET style params on the same request (an easy "uncomment this line" change, but a change regardless). Has that changed, or did you modify your CGI.pm?

Well, it hardly does anything at all, wouldn't you agree? It's just a dispatch table. All of the interesting stuff is in plugins to add Data::FormValidator and friends. That's not a negative to me. I think most people are going to build more on top of C::A if they use it for anything significant.

I would have the first button have a small Javascripty-doo that changes the hidden runmode field

I would have the first button have a small Javascripty-doo that changes the hidden runmode field . . .

Where I work, we have a significant number of users with JavaScript turned off (and it's staying off, as a lot of them are government users in departments with standing policies of not having JavaScript on).

<input type="submit" name="rm" value="Update users" >
[download]