I came across the same requirements under similar circumstances. What
I ended up doing was creating a new accessor/mutator method that kept
a data structure of all run modes that required authentication, I
named this login_run_modes.
I then overrode the cgiapp_prerun method to check if
$self->get_current_runmode() existed within my structure of run modes
requiring authentication. If it did then it changed run modes to the
login run mode using the prerun_mode() method.
Why did I do it this way? First off, I wanted to be able to centrally
manage all the run modes that required auth from one location. I
didn't want to put "checks" at arbitrary places to ensure this.
Secondly, with the structure of C::A it makes sense to make checks in
cgiapp_prerun as this is the only place where you can call
prerun_mode() from (at least that's what the POD says).
Without boring you to death, the code roughly looks like:
sub setup
{
....
$self->login_run_modes('some', 'list', 'of', 'run', 'modes');
....
}
sub login_run_modes
{
# store run modes in structure and return structure if no params given
}
sub cgiapp_prerun
{
if (exists $self->login_run_modes(){$self->get_current_runmode()})
{
$self->prerun_mode($someLoginRunMode);
}
}
On 12/19/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Influenced by a long thread that I started over the weekend about the
> number of run modes "allowed" in an application, I've been breaking my one
> large app into several. I have a question about turning control back to
> another module.
>
>
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
