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

[Stephen Howard <suppressed>]

Michael Graham wrote:

> > 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.
> >    
>
> WWW::Pipeline looks interesting.  A question: how hard would it be to
> use CGI::Application::Plugin modules in a WWW::Pipeline application?
>
> Not that I have any plans to switch, but it does seem to me that as
> more and more web platforms appear, it becomes harder to reuse common
> modules (and right now, CGI::Application has a rich set of these).
>  
Well, plugins wouldn't be reusable as-is, as the nature of plugins use 
less magic and are more explicit in Application::Pipeline, than in 
C::A.  The application that wishes to use a plugin explicitly runs 
$self->loadPlugin() to use a plugin.  And plugins themselves need a 
load() method, which is what loadPlugin calls.  That said, it would be 
fairly trivial to add a load() method to C::A plugins and have them 
compatible with App::Pipeline.  For callbacks, however, there is the 
issue of consensus on names.  WWW::Pipeline uses
Initialization ParseRequest GenerateResponse SendResponse Teardown

Where I believe that C::A's 'phases' are the previously overridden 
methods of setup,prerun,postrun,teardown, etc....  But for non-callback 
plugins this wouldn't be an issue.

I noticed in the C::A v4.0 docs on plugins mention storing plugin-data 
in the application object.  While none of the plugins I've written do 
this and I've not thought about it before, I'd tend to think this would 
be a bad idea.  Even though plugins are a mixin kind of deal, I think 
keeping data more cleanly separated would be appropriate.  Using the 
param() method might be ok, but for further data storage I'd think of 
making the plugin object oriented.  For example, instead of importing 
tt_process et al as C::A::P::TT does (not to pick on you, Cees :-P ), 
A::P::S::Template hangs the template object off the application, so 
instead you do this:

$application->template->proces(...)

Ok, enough rambling from me for tonight.  Swapping plugins is an 
interesting idea though.

-Stephen

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