Cees --
On 2005-12-21, Cees Hek <[EMAIL PROTECTED]> wrote:
>
> I guess my last message didn't come across as intended, as I am not
> disagreeing with you on the need for this standardization. I think it
> is a very important step to take. But it seems to me you are
> defending a specific implementation of this problem and making it look
> like it is the only solution (ie adding a stub method to the core).
> All I am saying is that adding a stub into the core is not the only
> way of solving this particular problem, and it would be worthwhile
> looking at alternative implementations as well.
>
> What I am afraid of is that we will end up with a whole bunch of
> methods in the core that are nothing more than placeholders. This
> would further complicate the docs, and add methods that do absolutely
> nothing without extra modules/plugins. I know that there are already
> lots of empty stub methods in the core, but they are intended to be
> subclassed and overridden, and are never called directly, they are
> only called by CGI::Application internally. So I believe there is a
> difference here.
>
> So let me suggest one possible alternative.
>
> From what I can see, there are only two main requirements. If we look
> at the config example, this is what I think is required:
>
> 1. common interface that all config plugins should adhere to
> 2. allow other plugins to painlessly call this common interface (even
> if the application is not actually using a config plugin)
>
> I think that it is requirement number 2 that is pushing you to put a
> config stub in the core. However, there is an alternative that would
> allow us to have the config stub in a plugin
> (CGI::Application::Plugin::Config) and still match the requirements.
>
> The first requirement is easily met with a plugin, since it will
> define a standard API that all Config plugins should adhere to. The
> actual CAP::Config plugin will only provide stub methods that a real
> plugin can link into (perhaps by registering themselves with
> CAP::Config when they are loaded)
>
> package CGI::Application::Plugin::Config::FancyXML;
>
> use CGI::Application::Plugin::Config;
> CGI::Application::Plugin::Config->register('FancyXML');
> ### more stuff here to fully implement whatever api there is
>
>
> So that will cover requirement 1. For requirement 2, what we would
> need is for a plugin to be able to load other plugins on demand. So
> the CAP::Session plugin could then load the CAP::Config plugin at
> startup so that it knows the Config interface will be available later
> on when it needs it (note that I didn't say load the Config::FancyXML
> plugin, as it only really needs the stubs to be in place which are
> provided by CAP::Config).
>
> package CGI::Application::Plugin::Session;
>
> sub import {
> my $class = shift;
> my $app = caller;
> $app->load_plugin('Config');
> }
>
> What this will do is make sure the that CAP::Config stub methods are
> loaded for the Session plugin to use later on. If the user has also
> loaded the Config::FancyXML plugin somewhere else, then the Session
> plugin may very well get some valid configuration data when it calls
> $self->config. If however the user is not using a Config plugin, then
> the stub will return undef for all calls to $self->config and the
> Session plugin will just need to look elsewhere for it's
> configuration.
>
> my $session_options = $self->config('Session_options')
> || $self->session_config()
> || $self->session_defaults;
>
> That should be sufficient to deal with requirement 2. It means adding
> an extra line to your plugins to tell it what plugins it depends on,
> but that shouldn't be that onerous.
>
> So all that is required for us to be able to pull the config stubs out
> of the core and into a plugin is the ability for a plugin to load
> another plugin. And as a side-effect, users can also load their
> plugins the same way.
>
> package My::App;
>
> use base qw(CGI::Application);
> use CGI::Application::Plugin;
>
> My::App->load_plugin(
> 'My::Custom::Plugin',
> ['Config::FancyXML' => '/etc/myapp.conf'],
> 'TT',
> 'Session',
> );
>
> And once we have a load_plugin method that actually loads the plugins,
> we can also do some more tricks like calling a standard initialization
> method in the plugin when it is loaded (this would take the place of
> the current 'import' method):
>
> package CAP::Session;
>
> sub plugin_init {
> my $class = shift;
> $class->load_plugin('Config');
> $class->export_methods(qw/session session_cookie .../);
> return 1;
> }
>
>
> And since you probably saw me sneak in the 'export_methods' call in
> there, we can do some sanity checks on the methods we are importing
> into the application namespace to check for method name conflicts.
> Now that I think about it, it actually might be easier to do the
> method exporting with global variables so that it is similar to the
> way Exporter does it:
>
> package CAP::Session;
>
> our @EXPORT = qw/session/;
> our @EXPORT_OK = qw/session_cookie session_config/;
>
> sub plugin_init {
> my $class = shift;
> $class->load_plugin('Config');
> return 1;
> }
>
> Then the load_plugin method can look at these variables (whatever we
> decide to call them) and decide what methods need to be exported.
> Optional methods can then be specified directly in the call to
> 'load_plugin'. You could even go so far as to allow method attributes
> as well.
>
> sub session : RequiredExport { ... }
> sub session_cookie : OptionalExport { ... }
Cees,
I'm with you 100% on the CAP::Config proposal. The rest of it I think
can support, although at the end it starts to look like re-inventing
import/exporting. So I'd like to discuss the added value of that more.
Would you like to turn that into a more formal POD/code proposal or
should I work on something?
> ps I wrote this last night, but decided to wait until today to send
> it. During that time it seems there is now a new plugin called
> CGI::Application::Pluggable...
Interesting... but I'll defer comment on C::A::Pluggable to keep the
conversation
focused.
Mark
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/[email protected]/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
