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 <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
---------------------------------------------------------------------
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
Mail converted by mhonarc 2.6.15
This archive provided courtesy of JSW4.NET, Internet Hosting Services for Small Business.