Re: [cgiapp] Re: Yet another callback system proposal

[Michael Graham <suppressed>]

Mark Stosberg <suppressed> wrote:
> It would seem that the numbers could be removed and replaced with an
> ordered list that services are used in:
>
>   init
>   config
>   database
>   session
>   logging
>
>   logging  teardown
>   session  teardown
>   database teardown
>
> Of course, CGI::App already has some of this with its various stages of
> execution.
>
> Where this is heading seems suspiciously like Stephen Howard's
> Application::Pipeline and WWW::Pipeline modules:
>
> http://search.cpan.org/~howars/Application-Pipeline-0.1.1/lib/Application/Pipeline.pm
>
> I felt that approach was too abstracted at the time, but it includes
> features which now seem desirable for CGI::Application:
>   - Plugin support via callbacks
>   - The ability to define new named execution stages
>
> It seems worth a look as fuel for the discussion if you haven't reviewed
> it recently.

Thanks for pointing me to WWW::Pipeline - I had heard of it but I hadn't
had a look yet.

Interestingly, WWW::Pipeline also doesn't support a sophisticated
positional scheme.  It has only five stages for every phase:

    FIRST EARLY MIDDLE LATE LAST

This got me thinking.  It made me realize that what I really want is
not a sophisticated set of positions at the init phase, but rather just
a bunch of named hooks that I can call from the init phase.

And we have this already with the proposed callback patch:

    package My::Database::Plugin;

    sub import {
        my $caller = caller;
        $caller->new_hook('database_setup');
        $caller->add_callback('database_setup', \&setup_tables);
    }
    sub setup_tables {
        # initialize all the Class::DBI tables
        # at the start of every request
    }

    ...

    package My::Project;

    My::Project->add_callback('init', \&my_project_init);

    sub my_project_init {
        my $self = shift;

        $self->new_hook('database_setup');  # just in case it's
                                            # not defined

        $self->call_hook('database_setup');
    }

This works very well for me - I can have as many database classes as I
want, and the Project doesn't have to know about any of them.  But at
the same time, the Project still has explicit control over exactly when
the database setup happens.  Which is as it should be.


Michael


-----------------------------------------------------------------------
Michael Graham <suppressed>

YAPC::NA 2005 Toronto - http://www.yapc.org/America/ - suppressed
-----------------------------------------------------------------------


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
              http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed