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.