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

Re: Why CGI::Application?

by dragonchild (Archbishop)
on Jan 13, 2004 at 13:10 UTC ( [id://320946]=note: print w/replies, xml ) Need Help??

in reply to Why CGI::Application?

Being someone who just implemented his first CGI::Application code yesterday (replacing a current app), let me tell you what C::A does for you.
  1. You are now explicitly implementing portions of your website as a state machine. This aids documentation and maintainability by naming your if-else blocks.
  2. The state machine control-code is now done for you.
  3. You are more easily implementing MVC, with C::A as your Controller code.
  4. It is very nice to see the code for many related pages all in one place.
  5. All your code now easily shares a print() method. (I have mine in my C::A superclass.) This allows for things like:
    sub some_state { my $self = shift; # do some stuff here to populate %template_params return $self->print( $display_mode, $template_name, %template_params, ); }
  6. Handling redirects and save-type pages is done for you. For an excellent example of this, check out
  7. You can accidentally turn your cgi-scripts into Apache handlers. (Well, it's a little more complicated than that, but it definitely gets you 90% of the way there.)

Also, you might be confusing something I was having issues with, at first. I originally thought I needed to implement my entire application as one monolithic C::A app. But, a friend of mine showed me what his company did. They have some 20 different C::A's that all work together, passing responsability off as necessary. They have one main C::A, which handles logging and the homepage. Then, every major subsystem (reports, user admin, preferences, etc) have their own C::A. If something is complicated, create another C::A inside that. His rule of thumb was 10-12 states, at most. More than that and you should look at breaking it up into two C::A's (if possible). Also, every one of your C::A's inherits from some abstract superclass that inherits from C::A, which implements things like how to connect to the DB, what CGI class to use, how to display, and other basic functionality.

We are the carpenters and bricklayers of the Information Age.

Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Replies are listed 'Best First'.
Re: Re: Why CGI::Application?
by Arunbear (Prior) on Jan 13, 2004 at 14:06 UTC
    I'm not sure how splitting into two or more C::A's would work (e.g. how would two C::A's interact?) - could you post a simple example of how to do it?
      Sure. I'll post a condensation of what I'm working on right now. The plan is this - you have a main C::A, where you handle logging in, the home page, and logging out. You also have a C::A that handles how reporting works. Remember - some of your users might not have the authority to run reports, so it's easier to just disallow the whole C::A than it is to disallow certain run-modes.

      Ok, so far so good. But, we don't have another C::A yet. I personally do my navigation through some header that I've TMPL_INCLUDE'd into all the relevant templates. (All of them, except login and logout.) The header basically has

      HOME => main.cgi?mode=home REPORTS => reports.cgi LOGOUT => main.cgi?mode=logout

      But, you wanted to see the other C::A. Here ya go:

      That's it. No handling of cookies, no handling of nothing. In fact, there's absolutely no way the cookies are NOT going to be handled. You can't forget to add it to the top. You can't forget to do standard processing. It's quite ... nice to be able to forget that you have it cause it just works.

      We are the carpenters and bricklayers of the Information Age.

      Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

        I like the idea of composing subclasses of C::A into the larger application, but I didn't see how you implemented this bit of the 'technical specification':

        " it's easier to just disallow the whole C::A than it is to disallow certain run-modes."

        If REPORTS => reports.cgi is in the navigation template on every page, then how do you prevent the user from executing that particular C::A? And I don't think that

        # Display some method of choosing reports, probably with some author +ization # checks in there

        inside sub choose counts; it's still disallowing a certain run-mode named "choose". :-)

        p.s. I enjoyed and learned something from being sidetracked by

        This is a tad on the late side. :-)

        The situation you discuss earlier is one that I'm also facing. I'd be interested in breaking a C::A into one or more C::As.

        I've tried to recreate the method you've used but I've hit a snag.

        You have

        package My::Application::Base; use CGI::Application; our @ISA = qw( CGI::Application ); sub setup{ # Do basic stuff, including run_modes everyone has, like 'redirect +_login' }
        Note the reference to run_modes. Later you have
        package My::Application::Reports; use My::Application::Base; our @ISA = qw( My::Application::Base ); sub setup{ my $self = shift; $self->runmodes([qw( choose display )]); }
        As far as I can tell the run_modes in Base are overwritten by the run_modes in Reports and I get a "No such run mode..." error when reffering to any run_mode in Base.

        Did you encounter this?

        Also, how would you implement such a scheme as this? Would each C::A have its own instance script?


        fwi, I've post my attempt here

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://320946]
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others pondering the Monastery: (8)
As of 2024-07-18 08:49 GMT
Find Nodes?
    Voting Booth?

    No recent polls found

    erzuuli‥ 🛈The London Perl and Raku Workshop takes place on 26th Oct 2024. If your company depends on Perl, please consider sponsoring and/or attending.