CGI Application Modules for CPAN

# save the message, then switch to list mode

sub save {

   my $self = shift;

   my $query = $self >query();  

   # ...

   return $self >list();

}

Just as in the earlier example, the  new  and  reply  run modes share the same 

underlying functionality. With CGI::Application this is easily done by having them 

both call the same private method, _edit():

# show edit screen with blank entry

sub new_message {

   my $self = shift;

   return $self >_edit();

}

# show edit screen with message quoted

sub reply {

  my $self = shift;

  my $query = $self >query;

  my $reply_id = $query >param( reply_id );

  return $self >_edit(reply_to => $reply_id); 

}

The _edit() method isn't listed as a run mode, so it can't be called directly by 

users. This is an important feature if users could access arbitrary methods, then 

CGI::Application would be a security breach waiting to happen!

The end result is a system that allows you to directly express the flow control of 

your CGI system in code. Instead of using an ad hoc flow control mechanism to 

guess which action to perform, CGI::Application modules use a table of run modes 

that map the contents of the run mode parameter to methods in the class. And as 

I'll explore later, by building your applications as modules rather than scripts, 

you'll be able to reuse them in multiple projects and even release them on CPAN.

Advanced CGI::Application

The use of CGI::Application shown previously is enough to accomplish a great 

improvement in CGI development. By abstracting your application logic into a 

series of run modes, you'll immediately get a cleaner and more comprehensible 

structure. This section will show how CGI::Application can be used to add further 

improvements.

26

263

3