Bound for CPAN: Reviews Requested for Application::Pipeline

[AidanLee]

This set of modules grew out of discussion on the CGI::Application mailing list.

There have been a number of times throughout CGI::Application's lifespan where mailing list members have asked for the ability to inject code inbetween different parts of the request-response process provided by the module. This has led to a proliferation of hard-coded, slightly awkwardly named phases which users can override in their subclasses. But whether you use them or not, all of the phases are always there. And there will likely come a time when someone wants yet another insertion point. This is the first issue that Application::Pipeline tries to address.

A lot of people have also sought either a) alternatives to the convenience methods provided by CGI::Application, or b) want to glue their own favorite Way To Do It more closely to CGI::Application. Right now, CGI.pm and HTML::Template have somewhat priveledged status by being integrated into the core of CGI::Application. Certainly it was not a bad decision at the time of C::A's first writing, but it now has a broad enough user base that there are quite a few of us using alternatives to these modules. Jesse has provided ways of working around this integration, but ultimately it is still a work around. This is the second issue that Application::Pipeline tries to address.

Docs, Source Code, Example Script

I am at the stage where I have working code, and a lot of documentation written. I have not yet gotten to writing tests. What I am looking for right now is constructive criticism on the API, how things could be done better internally, and any other comments that might make this module more worthy of posting to CPAN.

[DrHyde]

Submit it to Simon Cozens's code-review mailing list.

[PodMaster]

The %plan/phases makes sense, but that's about it. (It'd be fairly easy to retrofit CGI::Application so it uses the same concepts and behaves by default like CGI::Application does now, ie default application loop...).

The so called plugin interface is what makes the least sense. CGI::Application's template stuff was too specific, but yours is not generic enough. loadPlugin/loadPlugins/addService? I think you're going a tad overboard here (too much "architecture" that accomplishes nothing). I would simply look to borrow ideas from (or make use of) Class::Accessor and Class::Delegation to simplify creation of accessors/proxy methods if people want them, and it seem like they do. Something like

package Conan::O'Brien;
use CGI::Simple;
use base qw[ CGI::Pipeline ]; # or whatever

__PACKAGE__->proxyaxx(
    param => 'query',             # $self->param( 'query' );
    proxy => qw[ param ],         # $self->param(1) calls $self->param
+('query')->param(1);
    name  => 'query',             # $self->query() returns $self->para
+m('query')
    addHandler => [ Init, 'method', $stage ], # calls method on query 
+during $stage
);

sub setup {
    my $self = shift;
    $self->param( query => CGI::Simple::->new() ); # so now query/para
+m work
}

What made the least sense about plugins was the fragmentation of the namespace. CGI::Pipeline and WWW::Pipeline (its not like CGI::Simple and Calendar::Simple are related)? Should've been CGI::Pipeline::Plugin (like Template::Plugin).

And then the "basic services" (header/param) end up in WWW::Pipeline::Services so CGI::Pipieline has nothing to do with CGI anymore.

update: I almost forgot, if you stick with what you currently have, it'd be a good idea to restructure your distribution (you probably would've anyway), so that the tarball expands to something like

CGI-Plugin-0.01/
lib/
lib/CGI
lib/CGI/Plugin.pm
lib/WWW
lib/WWW/Plugin
...
Makefile.PL
README
...

update: d'oh, i see i keep saying CGI::Pipeline for some reason, lol (late night)

[AidanLee]

This is great stuff, but I think you're a bit confused about the namespaces i've chosen (unless i've got typos somewhere, though i did run a grep on the directory, so i don't think so).

The two main namespaces I'm using are Application::Pipeline and WWW::Pipeline, where the latter is a subclass with phases that suit HTTP request processing.

Obviously while i thought long and hard about the plugin/services bit, and tried to match what a lot of people were asking for on the mailing list, i didn't do much research on what is already out there. I'll take a look around.

Anyone else?

[AidanLee]

Well, I Read up on Class::Accessor and Class::Delegation. The latter didn't seem particularly applicable to my situation, I took the time to look through Class::Accessor's source code. The way it sets accessors/mutators is actually quite similar to the technique I use for adding services that are just accessors.

So while it's nice to see that i was thinking along similar lines for that, the addServices provides for more than simple accessors/mutators, as it can be passed any subroutine reference to be installed as a class method, as well as any object which it will build an accessor for.

I'm also, after thinking on it some more, not so convinced that it's such a bad thing that the code really only addresses architecture. Because that was precisely my intention. It is up to the subclasses to use the architecture to accomplish something. As soon as i try to make the base class accomplish something beyond being a framework, i've made assumptions on how people want to use this code (much the same as how CGI::Application is primarily a frame work for the Run Mode paradigm, but integrates CGI.pm and HTML::Template as useful tools).

For an example of a module that 'does something', take a look at WWW::Pipeline::Example. I should note here that if you don't want to download the tarball, click on any documentation link and then change the .html to a .pm to see the original source.

As far as extensability metaphors go, I haven't thought of a better one than the concept of a Plugin as being a package that bundles services and handlers.

I hope this gives a bit more insight into the design decisions I've made so far.

[Ctrl-z]

i think CGI::Application is great. Really great.

But I never use it. For similar reasons that you wrote Apllication::Pipeline.

but heres the thing; I can write my own baseclass framework that suits my applications perfectly.
And put in whatever handlers/plugins/doodahs i need, when i need them.

Application::Pipeline seems like a pretty neat module; I am not dissing that at all. But I see a fundamental flaw with these "just add water" frameworks; the choice between:
• warping my code round an insufficent framework
• importing and wading through a bunch of generic stuff i dont need
• spending a morning hacking a custom-fit solution
is no choice at all. Know what I mean?

update: what i mean is: IMO there is no happy medium between a simple or bloated "Application Framework". And the general mechanisms involved are too simple to appeal to compromise in the name of "Code-Reuse".

[Anonymous Monk]

I will be keeping an eye on this module as I try to work out how to move my game from my server to my players' machines. It seems to me that most frameworks like CGI end up have the tail wagging the dog, rather than the other way around. I shouldn't have to rewrite my application just to move it from being a CGI application to a Tk one. I just want to plugin the different front ends that I can choose to present my application, rather than have to rework my back end to fit in. I think this module offers me such a framework. Disabuse me of this idea, if you think this is wrong.

[AidanLee]

I think it is certainly a possible use. It is not one i have explored, but I'd certainly be interested in hearing what you might eventually make of it.