Cees,
So a plugin author would
use base CGI::Application::Plugin;
in their plugin, and that would be it?
Separately, how would a CGI::Application app author
get access to the plugin methods? What makes the
Plugin available to the CGI::Application app -
CGI:Application (though you said no mod to C::A code)
or else the C::A app itself?
Thanks.
Bill
--- Cees Hek <cees@xxxxxxxxxxxxxxxx> wrote:
> Mark Stosberg wrote:
> >>It simplifies and standardizes the way a plugin
> can be built for
> >>CGI::Application, and it works completely outside
> of the
> >>CGI::Application codebase (ie no patches
> necesary). It avoids the
> >>annoyances of building a big inheritance tree for
> the plugins you want
> >>to use by copying a given set of methods into the
> callers namespace. No
> >>exporting or name space munging needs to be done
> by the plugin modules,
> >>as this is done automatically.
> >
> > Thanks for contributing this. I'm not sure I "get
> it", though. It looks
> > like you have re-invented a way for some methods
> in a plugin module to
> > be exported, while others are not.
> >
> > Without this framework, CGI::App::Session worked
> fine and was as easy to
> > use as I hoped a plug-in would be. What's the
> additional value that this
> > framework provides over the techniques used for
> that?
>
> You are correct in seeing that
> CGI::Application::Session does not gain
> any new and magical functionality by using the
> plugin module. The users
> of the module won't notice any difference.
>
> What this does provide though is a standardized
> mechanism for building
> plugins for CGI::Application. Currently it is up to
> the plugin author
> to decide how to deal with the implementation. Here
> are some of the
> methods that are currently being used:
>
> - CGI::Application::Session uses a 'package
> CGI::Application;' directive
> in the code that writes several methods directly
> into the
> CGI::Application namespace (ugly)
> - CGI::Application::TT (not yet released, but
> previewed) uses the old
> inheritance trick (only practical when using a small
> number of plugin
> modules)
> - CGI::Application::ValidateRM uses Exporter to
> export it's methods (Works)
>
> So there are three plugin modules that each
> accomplish the same task in
> a different way. The task is to get some methods
> added to the class
> that is using the plugin.
>
> All the C::A::Plugin module does is try to provide a
> standard method of
> writing a plugin class for CGI::App, and it does it
> in a way that makes
> it very easy for the plugin writer (no need to worry
> about namespaces or
> using Exporter, it is all handled for you).
>
> So the benefit is for the plugin writer, not the
> plugin user.
>
> Cheers,
>
> Cees
>
>
---------------------------------------------------------------------
> Web Archive:
>
http://www.mail-archive.com/cgiapp@xxxxxxxxxxxxxxxxx/
>
> http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
> To unsubscribe, e-mail:
> cgiapp-unsubscribe@xxxxxxxxxxxxxxxxx
> For additional commands, e-mail:
> cgiapp-help@xxxxxxxxxxxxxxxxx
>
>
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/cgiapp@xxxxxxxxxxxxxxxxx/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: cgiapp-unsubscribe@xxxxxxxxxxxxxxxxx
For additional commands, e-mail: cgiapp-help@xxxxxxxxxxxxxxxxx
|
