Re: [cgiapp] Re: CGI::Application::Session - session plugin for CGI::Application

[Stephen Howard <suppressed>]

but of course, i percieve the pipeline to be different

initialization: cgiapp_init(), setup()
parse request:  cgiapp_get_query(), determine run mode, cgiapp_prerun()
build response: run(), which calls your run mode
send response:  cgiapp_postrun()
cleanup: teardown()

now what i don't know is if people like the idea of having defined 
pipeline stages for which you can install handlers before, during and 
after, is whether enough of us could agree on what the pipeline stages 
are.  I thought it might be possible to let people define their own 
pipeline stages, but suspect it would make inheritence a nightmare, even 
if we started with a reasonable set of defaults.  That would be a debate 
I leave open to the rest of the list.  but a brief example could go 
something like

$app->register( &method,
   stage     => 'stage name'
   at        => before | after | during  #optional, default 'during'
   overwrite => 0|1                      #optional, default 1
);

$app->register( \&cgiapp_get_query, stage=> 'parse request', at => 
'before' );
$app->register( \&grep_runmode,     stage=> 'parse request' );
$app->register( \&cgiapp_prerun,    stage=> 'parse request', at => 
'after' );

or perhaps you would want to be able to set it up as a data structure, 
similar to how run modes are traditionally done.

Kinyon, Rob wrote:

> To continue this concept, would it be beneficial to have a few different
> @pipelines that are generic lists of method names / CODErefs to call in
> a specific order at a specific time? For example, there could be three
> pipelines (with their current methods):
> 1) Initial setup
>    cgiapp_init()
> 2) Per-request actions
>    setup()
>    cgiapp_prerun()
>    run()
>    cgiapp_postrun()
>    teardown()
> 3) Final teardown
>    <nothing>
>
> Those, to me, are the three basic areas where actions can occur. Then,
> you could have methods like:
>    get_initial()
>    push_initial()
>    pop_initial()
>    shift_initial()
>    unshift_initial()
> (All dealing with the initial setup pipeline. You'd have similar methods
> for the per_request and teardown pipelines.)
>
> This would allow you to specify any sort of actions at any point in the
> pipeline.
>
> How does Apache2 handle this? Would there be the capability of either
> mimicking or stealing what they've done and implementing it in C::A?
>
> Rob
>
> -----Original Message-----
> From: Stephen Howard [mailto:suppressed 
> Sent: Wednesday, January 21, 2004 10:41 AM
> To: suppressed
> Subject: Re: [cgiapp] Re: CGI::Application::Session - session plugin for
> CGI::Application
>
> This is something I've been thinking about in a slightly broader sense, 
> as I've watched C::A mature.  As time has gone on, people have requested
>
> the ability to insert code into certain stages of the C::A process, and 
> what we've wound up with is something like (if memory serves me right):
>
> cgiapp_init
> setup
> cgiapp_prerun
> run
> cgiapp_postrun
> teardown
>
> which is starting to look like quite a pipeline to me.  But while it's a
>
> pretty good model for what most of us are doing (myself included), it's 
> really quite specific about what happens at each stage of our pipeline.
>
> And there isn't a way for the module user themselves to dynamically add 
> to this pipeline without a) making a derivative C::A, b) bugging Jesse 
> with 'yet another pipeline stage', or c) playing with Aspects or 
> Hook::LexWrap.
>
> I was wondering if it might be possible to come up with an architecture 
> for C::A that acknowledged the pipeline nature of handling requests, 
> rather than just the singular 'run mode' and somehow enabled the 
> developer to shape that pipeline how they may.  Such an approach feels 
> (to me) akin to the elegant solution Jesse has created for determining 
> run modes.
>
> How this ties in with the email i'm responding to is that each module 
> would need a way to register their pipeline stages with C::A.  Each 
> subclass could choose to either override it's parent classes' methods 
> for that stage or choose to be prepended to them.
>
> -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