> I predict great debate on this one :-).
Yeah, it should be interesting. :)
Before anyone gets too worried, I would like to point out that this
proposal would not require a core change to C::A, but could be
implemented with a plugin using the existing plugin system.
> I understand your motive here, but it's a weak argument. /Every/ module we
> authors use needs to be used according to its documented interface. So we have
> to read the docs. It would be a little bit nicer if config-type plugins all
> had
> a similar naming convention, but its hardly a driving problem.
Here's what I see as the benefits to a unified config API.
At the moment, each of the config plugins has its own documented
interface for retrieving configuration.
And (as you point out) each CA Plugin that requires configuration has
its own documented interface as well.
So my personal cgiapp_init is basically a hundred lines of this:
Step 1: fetch the config data needed for plugin A
Step 2: massage the config data
Step 3: feed the data to plugin A
Steps 4-20: repeat for plugins B through Z
If each of the plugins that required configuration declared their needs
in a formal way, and each of the config plugins supported a consistent
interface, then I could just say:
use CAP::A;
use CAP::B;
use CAP::C;
...
That would reduce the size and complexity of my base class a lot.
It would also make using plugins a lot easier. Plugins could even
provide config file examples in popular formats. For instance,
CAP::Session could say:
To use this plugin, first add the following line to your application
or base class:
use CGI::Application::Plugin::Session;
This plugin is usable out of the box and does not require any
configuration. However if you want to change the defaults, you can
do so through your application config file. Here are some examples
(using various popular configuration systems):
# CAP::Config::Context
<session_options>
driver file
directory /tmp
send_cookie = 1
</session_options>
# CAP::ConfigAuto (perl mode)
$config = {
session_options => {
driver => 'file',
directory => '/tmp',
send_cookie => '1',
}
};
So it's mostly a matter of convention and of standardizing interfaces,
with a tiny bit of glue to make it all work.
There are some issues to sort out, but they're not huge:
* need a clean way of dealing with config formats that don't support
hierarchical data structures.
* plugins that want a database handle should be encouraged to look
to $self->dbh before they get their connection info from the
config file.
* Any other computed config values that plugins typically need?
* It might be reasonable to allow multiple config 'providers'. For
instance having a 'root_dir' param available that all plugins can
rely on could be a really useful thing.
But if the app is running under PAR, then maybe 'root_dir' is in
some magical faraway place under $ENV{'PAR_TMP'}, and maybe the
exact directory name isn't known until runtime. In this case, the
system could allow the PAR plugin to override this single
parameter only.
Michael
---
Michael Graham <[EMAIL PROTECTED]>
---------------------------------------------------------------------
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]
