Re: avoiding excessive number of methods in CGI::Application and DBI modules

If I understand your situation correctly, it seems you need four CRUD functions that have the same functionality but differ in their specifics. If it were my project, that would immediately lead me to create four generic CRUD methods with the specifics passed as parameters.

Taken from the CGI::Application docs:

The param() method enables a very valuable system for customizing your applications on a per-instance basis. One Application Module might be instantiated by different Instance Scripts. Each Instance Script might set different values for a set of parameters. This allows similar applications to share a common code-base, but behave differently. For example, imagine a mail form application with a single Application Module, but multiple Instance Scripts. Each Instance Script might specify a different recipient. Another example would be a web bulletin boards system. There could be multiple boards, each with a different topic and set of administrators.

The new() method provides a shortcut for specifying a number of run-time parameters at once. Internally, CGI::Application calls the param() method to set these properties. The param() method is a powerful tool for greatly increasing your application's re-usability.

Hope that helps!

Comment on Re: avoiding excessive number of methods in CGI::Application and DBI modules

Replies are listed 'Best First'.
Re^2: avoiding excessive number of methods in CGI::Application and DBI modules by Tanktalus (Canon) on May 01, 2005 at 18:05 UTC
That's fine if you want a bunch of different .cgi scripts. But, if you want them all in the same script for some reason, perl gives you lots of rope to do this with. `sub setup { my $self = shift; for my $table in (@tables) { # define @tables elsewhere $self->run_modes( "c_$table" => sub { $self->do_c($table); }, "r_$table" => sub { $self->do_r($table); }, "u_$table" => sub { $self->do_u($table); }, "d_$table" => sub { $self->do_d($table); }, ); } }` [download] Different .cgi scripts is great when you're giving your C::A-based module to others to use, as it provides some simple flexibility to the middle-man. But, I'm not so fond of it for general use. They actually confuse me. Maybe I'm easily confused about this, I suppose. Either way, this is just another WTDI.	[reply] [d/l]

Replies are listed 'Best First'.

Re^2: avoiding excessive number of methods in CGI::Application and DBI modules
by Tanktalus (Canon) on May 01, 2005 at 18:05 UTC

That's fine if you want a bunch of different .cgi scripts. But, if you want them all in the same script for some reason, perl gives you lots of rope to do this with.

sub setup {
  my $self = shift;
  for my $table in (@tables) { # define @tables elsewhere
    $self->run_modes(
      "c_$table" => sub { $self->do_c($table); },
      "r_$table" => sub { $self->do_r($table); },
      "u_$table" => sub { $self->do_u($table); },
      "d_$table" => sub { $self->do_d($table); },
    );
  }
}
[download]

[reply]
[d/l]