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

---

---

• Are you posting in the right place? Check out Where do I post X? to know for sure.
• Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:

  <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>

• Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
• Want more info? How to link or How to display code and escape characters are good places to start.