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
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).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 }
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)
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
For: | Use: | ||
& | & | ||
< | < | ||
> | > | ||
[ | [ | ||
] | ] |