$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.