Beefy Boxes and Bandwidth Generously Provided by pair Networks
Clear questions and runnable code
get the best and fastest answer
 
PerlMonks  

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

by aroc725 (Acolyte)
on May 01, 2005 at 15:05 UTC ( [id://453018]=perlquestion: print w/replies, xml ) Need Help??

aroc725 has asked for the wisdom of the Perl Monks concerning the following question:

Recently I used the CGI::Application framework, as well as the DBI interface and the HTML::Template module to develop a survey Web application.

This approach worked very well, but the application needed only a couple of database tables (one for the survey answers and another for lookup values).

But if the application required say, 20 tables, and I needed 4 run-modes to implement 'CRUD' (Create/Read/Update/Delete) functionality for each table, then it would seem to me that I'd end up with 80 methods in my 'CGI::Application' module and another 80 methods in my DBI module. (The application module passes submitted form data to functions in the DBI module).

Is there a(n easy) way to avoid this scenario ?

Replies are listed 'Best First'.
Re: avoiding excessive number of methods in CGI::Application and DBI modules
by adrianh (Chancellor) on May 01, 2005 at 15:18 UTC
    Is there a(n easy) way to avoid this scenario ?

    If all the methods are doing different things why worry?

    If all the methods are doing similar things take the common behaviour and factor it out into stand alone modules - or look at something like Maypole or Catalyst which does most of the CRUD work for you.

Re: avoiding excessive number of methods in CGI::Application and DBI modules
by kwaping (Priest) on May 01, 2005 at 17:42 UTC
    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!

      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); }, ); } }
      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.

Re: avoiding excessive number of methods in CGI::Application and DBI modules
by Anonymous Monk on May 01, 2005 at 15:15 UTC
Re: avoiding excessive number of methods in CGI::Application and DBI modules
by dragonchild (Archbishop) on May 02, 2005 at 12:46 UTC
    Is there a(n easy) way to avoid this scenario ?

    Yes - don't design your application in a way that sucks.

    You're thinking as a DBA / programmer, not as a systems analyst. Think about how your application is going to be used. CGI::Application (and similar frameworks) provide user-level mapping to business-level concepts. I had an application that would CRUD over 40 tables. But, because there were only 7 different screens (with options), I had 7 runmodes. Now, based on those options, different things would happen.

    Here's another way to look at it - to run reports, I need 2 runmodes - PickReport() and RunReport(). However, I will probably want:

    • A class for each report
    • One or more base classes for those reports
    • A class for each parameter
    • One or more base classes for those parameters
    • One or more templates for each report (We had 3 - HTML, PDF, and XLS)
    • Internationalization support
    • Database layering
    • Images for look'n'feel

    In total, I think we ended up with some 250 files supporting 70 reports. Still only 2 runmodes, though ...


    The Perfect is the Enemy of the Good.

Log In?
Username:
Password:

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlquestion [id://453018]
Approved by b10m
Front-paged by tlm
help
Chatterbox?
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others surveying the Monastery: (4)
As of 2024-03-29 11:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    No recent polls found