If you do inherit both child-applications from the "main" application, do you instantiate the base first and then re-bless, or create a new child object when needed?

Or do you do something else entirely and have I misread your post?

Just curious

"What should it profit a man, if he should win a flame war, yet lose his cool?"

I don't inherit because there isn't really a parent-child relationship between the different modules. I'll explain in detail what I'm doing in my current project. It's done this way not because I designed it this way from scratch, but because I'm refactoring existing functionality from a mess of spagetti-code and using CGI::Application modules to split it up into managable pieces seemed like a good way to go.

Say I have 3 main pieces of code for a shopping cart - user management, product management, and order management. In this case, I'd have one CGI::Application module that works on the run mode "action" variable. So we'd have three run-modes: user, product, and order.

My "Main" CGI::Application would be using the "action" variable to decide the run-mode. It's only choices would be user, product, and order. Depending on which of these it is, it would instantiate another CGI::Application module of that type. So if the main run-mode is "user," it would do something like:

my $user_app = new UserApp(...);

The nice thing is that since each run-mode in "Main" is related to a different thing (user, product, or order), I can use those run-modes to set up the environment for each of those sub-run-modes differently. For example, if I have a "user" class which is used to do database interaction with the users table, I can create a user object and pass it to the User CGI::Application module as a parameter. That user object won't be created for the other modes if they don't need it.

I should probably post some code, I'll try to write it as I do it, but this is untested:



use strict;
use warnings;

package MainApp;

sub setup {
    my $self = shift;

    $self->tmpl_path('./templates/');
    $self->mode_param('action');
    $self->run_modes(
        product => 'product',
        order   => 'order',
        user    => 'user'
    );
}

sub product {
    my $self = shift;

    use Product;
    use ProductApp;

    my $p = new Product(); # Say this is an object with methods to int
+eract with the products database

    my $pa = new ProductApp(
        PARAMS => {
            p => $p
        }
        # more args...
    );

    return $pa->run();
}

sub order {
    # Similar to product()
}

sub user {
    # Similar to product()
}

package ProductApp;

sub setup {
    my $self = shift;

    $self->tmpl_path('./templates/');
    $self->mode_param('task');
    $self->run_modes(
        add    => 'add',
        edit   => 'edit',
        delete => 'delete'
    );
}

sub delete {
    my $self = shift;
    my $cgi  = $self->query();
    my $p    = $self->param('p');

    if($p->delete($cgi->param('product_id'))) {
        return "The product was deleted!";
    }
    else {
        return "There was a huge error.";
    }
}

1;
[download]

The thing to notice is that the sub-modules work off a different run-mode name ("task" vs. "action"), so if I wanted to grab that delete method, I could go like this:

http://some-url/?action=product&task=delete

And of course to actually get it to delete something you'd have to pass a product ID:

http://some-url/?action=product&task=delete&product_id=1234

The reason I have different classes/objects to do database interaction is because we do a lot of reports and processing with command-line scripts in addition to our CGI::Application modules. If they're abstracted out like that, we can use those interfaces to do stuff from command line scripts as well without having to rewrite the same DB queries in multiple places.

Anyway, I know this doesn't really address your question about inheritance, but I, like other people here, really don't like to use inheritance unless there is really a parent-child relationship. Generally, at least for me, there isn't such a relationshiop among various CGI::Application modules, as those don't contain much "real" logic - they are just interfaces to the real DB work that goes behind the scenes.

It sounds like SiteManager.pm is a repository for utility code. If that's the case, then it shouldn't inherit from CGI::Application. Going by the names you have, it sounds like EventManager and EmailManager aren't really kinds of SiteManagers; maybe all three are Managers. Inheritance should model "is-a" — if the child class doesn't quite fit, don't force it. That way lies madness.

Don't inherit from a superclass just for code reuse: there are plenty of good ways to reuse code; inheritance is one, but building libraries with clean interfaces is perfectly good, too, and doesn't complicate your life with weird dispatch semantics. If you have to ask "Should foo really subclass bar?", the answer is probably no.

well, the big reason i have SiteManager as a parent class is because the authentication lives there, and it's really simple auth.

other functions are utility functions.

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]

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

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

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

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

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.

Seconded. See my earlier reply to saberworks post. I've started using it in a real-world application and it works quite nicely. I have a couple patches into the author for some enhancements I needed, who seems willing to put them in. :-) If you're interested the patches include:
• Passing in the pre-translated application name to the application. Useful if you want to programatically create links between applications.
• Under CGI mode, pass-along any params set via new() in the instance script.
It makes it very easy to setup multiple applications w/o having to add <Location> (mod_perl) or instance scripts (CGI) for each one.

that, in fact, does look like the cleanest solution.

from the perldoc, i guess my  form action would just have the module name on it? like:

   <form name='add' method='post' action='/cgi-bin/index.cgi/EventMana
+ger/'>
[download]

and the hidden fields for RM would still apply?

I'm not quite sure how that works, as I've never used it myself. Try it out with a few toy classes and see what happens. Alternatively, you can ask on the CGI::Application mailing list, which is where I heard about this.

Being right, does not endow the right to be rude; politeness costs nothing.
Being unknowing, is not the same as being stupid.
Expressing a contrary opinion, whether to the individual or the group, is more often a sign of deeper thought than of cantankerous belligerence.
Do not mistake your goals as the only goals; your opinion as the only opinion; your confidence as correctness. Saying you know better is not the same as explaining you know better.