Hey all,
looks like i'm way late to this discussion, but I wanted to let you know
that I've been using WWW::Pipeline quite successfully as the framework
for our CMS, www.enterity.com/osiris, for some months now. And having
set up a very CGI::App-like environment via the RunMode plugin and
friends, I've found development to be very similar to working in
CGI::Application. I've recently been toying with a caching plugin that
intervenes 'EARLY' in the GenerateResponse phase, and have been pretty
happy with the limited stages. To be honest this is actually the first
time I've used anything other than the default MIDDLE stage. For a
while there I was wondering if I needed a mechanism to skip pipeline
stages, but realized that even though I was intervening in the normal
pipeline process, I was still doing a GenerateResponse kind of action,
so it wasn't appropriate to skip the rest of the stage once a cached
copy was found.
-Stephen
Michael Graham wrote:
Mark Stosberg <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]>
YAPC::NA 2005 Toronto - http://www.yapc.org/America/ - [EMAIL PROTECTED]
-----------------------------------------------------------------------
---------------------------------------------------------------------
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]
---------------------------------------------------------------------
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]
