On 2005-12-14, Michael Graham <[EMAIL PROTECTED]> wrote:
>
> For instance, right now we have at least four Config plugins, each with
> its own API.
>
> Module Methods Single Param Access
> ------ ------- -------------------
> CAP::Config::Simple config, config_param $self->config_param('foo')
> CAP::ConfigAuto cfg $self->cfg('foo')
> CAP::Config::YAML config_param $self->config_param('foo')
> CAP::Config::Context conf $self->conf->param('foo')
>
> If all these plugins could export a standard interface (without
> trampling on each other's exported methods) then maybe proliferation of
> Config plugins suddenly becomes a good thing because they are all
> compatible with each other. This is the approach that OpenPlugin was
> trying for, I believe. It's something I'd like to see addressed in
> C::A, but I'm not convinced a ground-up rewrite is the solution :)
ConfigAuto was first, and it as the shortest method name. Therefore,
it should win the "standard API" game.
Alternatively, We could choose none of the above and go with:
$self->config('foo');
Which I believe is what Catalyst does.
Why bother with the Catalyst API?
I'm not sure if people realize it, but sharing plugins with Catalyst is
close to a reality. In some cases, it already works, people just don't
mix-and-match like that.
For example, our HTML::Prototype plugin can be used with Catalyst
without modifications.
I think it does turn out that our plugins would be easier to use in
Catalyst than vice-versa. (We don't bother with the "$c" object that
Catalyst apps expect.).
Often, the plugins demand very little of the object that mix-into. Ours
often just seem to need a 'query' method. Catalyst could easily add one
in a compatibility if they chose.
Already we help each other as projects because we are both open source
and in Perl, so it's fairly easy to port plugin code between projects,
although it's not happening much now.
If we agreed on more things like plugin-loading and method names, then
we could potentially reduce redundant work on both sides of the fence
and mutually strengthen the image and reality of Perl as a powerful and
fun web development platform.
So I guess I just talked myself into agreeing on support Catalyst's config
API, but because it's special or cool, but because in the long run
compatibility may selfishly benefit us. At least it's simple.
http://search.cpan.org/~sri/Catalyst-5.61/lib/Catalyst.pm#%24c-%3Econfig
Mark
--
http://mark.stosberg.com/
---------------------------------------------------------------------
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]
