in reply to Breaking up a CGI::Application program

You know i was thinking of this exact same thing the other day.

Some ideas I had were creating each modularized class to handle database, templates/formatting, email, etc., loading them at the init of the app, and building each page from there. This would eliminate a lot of non-abstracted SQL, HTML, and even text, as well as organize everything so as to make it much more scaleable.

Instead of having to open up "WebApp.pm", search through 1000+ lines of code to change database connection settings, you could open up "WebApp::DBI.pm" and go right to the sub that handles database connections, wading through maybe 15 lines of code instead of the latter.

Just my $0.02 :-)

meh.

Replies are listed 'Best First'.
Re^2: Breaking up a CGI::Application program
by jdtoronto (Prior) on Jun 01, 2006 at 02:22 UTC
    One of the good reasons for using Class::DBI too! It keeps the database code all in one place, saves the agony of using placeholders and makes the whole thing a lot simpler.

    But for your particular situation dhoss there is a plugin from Mark Stosberg, CGI::Application::Plugin::DBH which puts the database initialisation in the cgiapp_init method. It even uses lazy loading so that if it is not required within a runmode the connection to the database is not made, thus saving time and bandwidth.

    samtregar also makes the very useful suggestion of using <tmpl_include ..> directives in templates, this is very useful. But don't forget to ponder the use of <tmpl_if ..> and <tmpl_unless ..> directives. Although coming dangerously close to incorporating code in the HTML, they do allow a very simple, and easily managed, method of controlling presentation of menues.

    Having said all of that, CGI::Application works best in a mod_perl environment when it gets to big applications. But that's the subject of another whole thread I think.

    jdtoronto

      CGI::Application::Plugin::DBH is quite nice, but i find myself doing a lot of SQL by hand that i shouldn't, especially since i'm not as versed in SQL as i should be for some of the queries i try and do.

      That's where Class::DBI or DBIx::Class comes in nice and handy, although I have trouble understanding how it handles relationships, but, that's a topic for another thread :-)

      meh.