CGI::Application provides a framework for tackling this very problem.

my %actions = (
  Register => \&handle_register,
  "Book Course"=> \&handle_book_course,
  # ...
);
# ...
if (defined $actions{$action}) {
  $actions{$action}->();
} else {
  print "No such action $action...";
}
[download]

Basically you have a hash giving a subref for each action. You can even write an anonymous subroutine in the dispatch table using the sub { ... code here ... } syntax. This should be pretty fast and allow you to easily add or remove actions, and have one action be callable by multiple names.

Note that calling a subroutine named by the action argument is a major security risk if you don't at least run checks to see if it's valid first.

An interesting twist on this idea is to put the 'dispatcher' part of the dispatch table concept into AUTOLOAD. You execute your 'actions' as method calls against an object. When perl doesnt find it it calls the dispatcher from AUTOLOAD and installs the subroutine from the dispatch table. This method may actually be a little insecure, depending on how you built your objects. You might want to use an special class, with no additional methods (even new) so someone can't call your personal routines for instance.

Another idea, more secure, is to use Perls class heirarchy as the dispatch function. Each action gets translated into a class name and then in an eval used and new()ed. The returned object is then manipulated as so desired. If you prepend a 'safe' root name to the class and the appropriate directory is secure then overall security shouldn't too much of an issue. Also a bit of s///g ing of $action first might be in order.

#untested
sub handle_action {
  my ($self,$action,$value)=@_;

  my $obj=eval "
                 use Some::Class::$action; 
                 Some::Class::$action->new()
               "; #eval returns the last value evaluated

  return $self->raiserror($action,$value,$@)
       unless $obj->is("Some::Class::Proto");

  $obj->exec($value);
}
[download]

well anyways those are some of the more unusual ways. :-) I like the class heirarchy the best in some ways cause it neatly modularizes the whole process.

Yves
--
You are not ready to use symrefs unless you already know why they are bad. -- tadmc (CLPM)

For one of my applications, I have all forms return an action (add, edit, delete, etc) and a type (Press Release, Press Cuttings, etc.). Then, I control the page and the function as follows:

#                    $action     $type
my %page_control = ( add    => { PressRelease => { page     => 'pm-mai
+n-pr-add.tmpl',
                                                   function => \&add_p
+ress_release },
                                 PressCutting => { page     => 'pm-mai
+n-pc-add.tmpl',
                                                   function => \&add_p
+ress_cutting }
                               },
                     edit   => { PressRelease => { page     => 'pm-mai
+n-pr-edit-del.tmpl',
                                                   function => \&edit_
+press_release },
                                 PressCutting => { page     => 'pm-mai
+n-pc-view.tmpl',
                                                   function => \&view_
+press_cuttings }
                               },
                     delete => { PressRelease => { page     => 'pm-mai
+n-pr-edit-del.tmpl',
                                                   function => \&delet
+e_press_release },
                                 PressCutting => { page     => '',
                                                   function => '' }
                               },
                     display=> { tabs         => { page     => 'pm-tab
+s.tmpl',
                                                   function => '' },
                                 menu         => { page     => 'pm-men
+u.tmpl',
                                                   function => '' }
                               },
                     default =>{ page     => 'pm-main.tmpl',
                                 function => \&show_main_console } );

my $page     = $page_control{ $action }{ $type }{ page };
my $function = $page_control{ $action }{ $type }{ function };

$page ||= $page_control{ default }{ page };
[download]

With that one data structure, it's relatively easy to track what's going on. However, I do want to look a bit more closely at CGI::Application as I lately hear its name getting bandied about quite a bit.

Cheers,
Ovid

Vote for paco!

Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

1. Your program consists of a single loop, consisting of what is really a big CASE statement (or SELECT, depending on your religion). You start with one of several initial states, based on your initial task.
2. Each CASE / SELECT entry (just use an if test like if (&mystate eq 'SomeValue') will do some processing or validation that is required at that step, and then makes a decision on what the next state should be.
3. The loop continues until you reach a "completed" state.

if (&mystate eq "REGISTER") {
    if (&UserName eq "") {
        &mystate = "ERROR";
        &error_code = "Missing user name";
    }
    else {
        &mystate = "CHECKADDRESS";
    }
}
[download]

Percentive monks will see that by using a sequence of IF blocks, within one pass of the loop, the program may pass through several states in sequence - that is not a problem. That advantage of this approach is that you have broken up your processing logic into a number of discrete chunks, each doing a particular function (validating an address, doing a data base search for a list of courses, whatever), and hence becomes easier to maintain.

As well, your business logic - what is required to process a course booking, for example, is listed in the logic of chosing the state progressions. So if you need ot add some additional business logic at a later stage (oops - we forgot that we need an email address when accepting course bookings), then you can add it reasonable simply.

I apologise if the explanation is a trifle obscure - one should not try to undertake algorithm design late on a friday evening!