in reply to CGI::Application, inheritance trees, and 'the right way'

I'm not quite sure I completely understand where you're going, but I'll sketch what I can see from here, and one way I might approach the issues.

I get the impression that you want to have a single module that then delegates to other sub-modules, all of which are CGI::Application-based. While I understand the desire to do that, I must say that when I have attempted this in the past, code maintenance has become a bit of a nightmare.

If you look through the CGI::Application mailing list and the wiki, you'll see a lot of people posting a rule of thumb: if you have more than 7 run modes, you should probably refactor into another module. Experience shows that if you get more than that, it becomes harder to maintain the code -- it's more difficult to scan through it to determine what happens when.

That said... what I'd recommend is keeping SiteManager as a CGI::Application superclass. Then have EventManager and EmailManager each inherit from it. If they need to extend or override functionality from SiteManager, let them. That means making SiteManager configurable -- don't have it doing things in cgiapp_init(), cgiapp_prerun(), cgiapp_postrun(), and teardown() that can't be overridden. Consider: 

    package SiteManager;
    sub cgiapp_init {
        my $self = shift;
        my $params = @_;
        if ($self->param('start_event')) {
            $event = new Event();
            $this->event = \$event;
        }
    }

    package EmailManager;
    sub cgiapp_init {
        my $self = shift;
        my $params = @_;
        $this->param('start_event', 1);
        parent::cgiapp_init();
        $self->SUPER::cgiapp_init($params);

        $email = new Email();
        $this->email = \$email;
    }

[download]
In this case, SiteManager has made creation of the event propery optional by asking for a parameter to be set before it will do so. The parameter could be set by either the instance script or, as in this case, the child class.

Typically, if you do something like this, you want to only put items in SiteManager that you're going to use over several child classes. So think about what you might need from a superclass that you'll use in your child classes and don't want to muck about with more than once: authentication, logging, insertion of content into a sitewide template, navigation, etc.

And don't be conned into doing the single script "paradigm"; it'll only cause headaches down the road. :-)

Replies are listed 'Best First'.
Re^2: CGI::Application, inheritance trees, and 'the right way'
by geektron (Curate) on Nov 02, 2004 at 07:36 UTC
    OK -- so i'm trying to get my head around this, and it's just confusing me.
    1. where is  $this coming from, and what is it supposed to reference?
    2. how does SiteManager dispatch sub-requests in this case? i can see that a new EventManager is instantiated, but when I tried it, i got an infinite loop
    maybe a better explanation of what i'm doing (or trying to do) is a better idea ...

    essentially, the admin side of this site has various management functions ( email editing, email sending, event calendar population ), and i'd like to keep on URL for the client so that he can just bookmark (or remember ) that and be done with it.

    because each 'set' of admin functions does different things, i'm trying to break those out into modules so that what got called for what set of functions is easier to find.

    i'm anticipating a menu (top or left, doesn't matter) where links like "manage email" and "manage events" will be, and those are the 'sets' of functions i'm using.

    i can see the links going to other CGI scripts, but the only thing that saves me, i think, is the confusion of trying the 'dispatch tables' i'm working towards now ...

[reply]
[d/l]

      $this was a typo; should have been $self.

      In the example, SiteManager isn't dispatching sub-requests; I should have used different names than those you'd given. I was considering the modules that SiteManager might load being not additional CGI::Application modules or modules that create output but API level things -- grabbing events for a calendar that needs to be displayed on every page, or a site navigation that needs to be custom generated on each page.

      You can still have a single page that your client can bookmark, but this might be more of a homepage with links to other applications. The applications would all inherit from SiteManager so that you get:

      • Centralized authentication
      • Centralized navigation
      • Sitewide template shell
      • etc.

      Another possibility would be to have an application that would dynamically instantiate and run() other CGI::Applications: 

          package SiteManager;
    use base qw/CGI::Application/;

    use EventManager;
    use EmailManager;

    sub setup {
        $self = shift;
        $self->run_modes(
            'events'    => 'events',
            'email'     => 'email
        );
    }

    sub events {
        $self = shift;

        # Initialize a params hash or grab it from a config file and t
+hen...
        $events = new EventManager($params);
        $events->run();
    }

    sub email {
        $self = shift;

        # Initialize a params hash or grab it from a config file and t
+hen...
        $email = new EmailManager($params);
        $email->run();
    }

      [download]

      However, even with this example, it might not be a bad idea to have a base class that takes care of authentication, site template, etc.

[reply]
[d/l]
      $this is probably a typo for $self - C++ & PHP use the name "this" rather than the perl way, which allows you to name it whatever you want.
[reply]
[d/l]
[select]
Re^2: CGI::Application, inheritance trees, and 'the right way'
by geektron (Curate) on Nov 02, 2004 at 04:53 UTC
    this is pretty much *exactly* what i'm looking to do.

    SiteManager has code like "login", a dbh() method ( to eliminate code like $self->param('DBH')->prepare() ), etc ... plus some "utility" functions.

    i already have a few apps with more than 7 run_modes, and they are a nightmare to maintain, so i've been following my gut and refactoring for ease of maintenance. I've inherited most of them, but a few i think i've authored new.

[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom