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. :-)

In reply to Re: CGI::Application, inheritance trees, and 'the right way' by weierophinney
in thread CGI::Application, inheritance trees, and 'the right way' by geektron

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":


  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.