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)

MJD says "you can't just make shit up and expect the computer to know what you mean, retardo!"
I run a Win32 PPM repository for perl 5.6.x and 5.8.x -- I take requests (README).
** The third rule of perl club is a statement of fact: pod is sexy.


In reply to Re: Bound for CPAN: Reviews Requested for Application::Pipeline by PodMaster
in thread Bound for CPAN: Reviews Requested for Application::Pipeline by AidanLee

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.