> > Bill Catlan wrote:
> >
> >> Just to set a reference point, do we all agree
> that
> >> everything we discussed would benefit from some
> agreed
> >> upon method of preventing namespace conflicts
> between
> >> plugins - no matter what space they are brought
> into?
>
> I think it is very worthwhile notifying the user if
> a namespace
> collision has occured. But I don't know if it is
> absolutely necesary to
> avoid name space collisions at all cost. Perl is
> about letting the
> programmer decide what is best.
>
> As long as some thought is put into writing the
> plugins, I don't really
> see a big problem here.
Yes and no. Thought is one thing, but having to
research the plugin methods exported by all /known/
plugins is another. As plugins proliferate, like we
hope, what a chore that would become. Respectfully, I
think avoiding name space collisions is essential.
Otherwise, your building in an (unnecessary) problem.
> Michael Peters wrote:
> > Ok, some more thoughts and ideas on all of this...
> [ snip ]
> > So, another idea I had was, that upon 'using' a
> plugin, it would export
> > only one method (which the user of the plugin
> would name) into the
> > application's namespace. This method would act as
> an accessor to every
> > other method you 'export' and also as a
> constructor for your plugin (if
> > you need one). Ok, example time. I'm redoing the
> above example with this...
> >
> >
> > package MyApp;
> > use base 'CGI::Application';
> > use CGI::Application::Plugin::TT name => 'tt';
> > use CGI::Application::Plugin::Config::Simple name
> =>'conf';
> >
> > [snip]
> > $self->tt->process(...);
> > my $param = $self->conf->param(..);
> >
>
> This method would work, but I think it has the
> possibility of adding new
> confusion, and it adds an extra level of
> indirection. I want to be able
> to write a plugin that replaces 'load_tmpl' for
> instance...
Shouldn't method overloading be done in a base class,
not a plugin? But, please see below for further
thoughts.
> What if we compromised, and allow for the ability to
> provide a prefix to
> the methods that are imported. But this prefix
> would be optional.
>
> package MyApp;
> use base 'CGI::Application';
> use CGI::Application::Plugin::TT;
> use CGI::Application::Plugin::Config::Simple prefix
> =>'conf_';
>
> [snip]
> $self->process(...);
> my $param = $self->conf_param(..);
>
> Here we see one plugin using a prefixed method, and
> another using the
> default.
I like Mike's idea about using an accessor better. I
like that it allows object caches and I prefer the
object oriented approach over descriptive prefixing.
But, I suppose the programmer could specify no
accessor name and achieve your result of having the
plugin methods clobber any previous methods defined in
a parent class. Or maybe a method attribute could
specify that behavior, and the app programmer could be
warned in the docs and/or logs.
>
> > This would eliviate the problem of having to use
> the application
> > module's internal hash for storage since each
> plugin would actually be
> > an object in itself. There would be no namespace
> issues between methods
> > since the user picks the name by which each plugin
> is accessible.
>
> But that object itself still needs to be stored in
> the application
> module's internal hash, otherwise you would be
> creating a new copy of
> the plugin object everytime you called it. So there
> is really no
> difference here.
>
> We can come up with a convention (use
> $self->{__PLUGINS}->{__SESSION} if
> the module is called CGI::Application::Session). We
> could probably even
> standardize that by using the param method in C::A
> and
> UNIVERSAL::moniker to come up with a key name. And
> then we could even
> wrap that up in a method to be added to the plugin
> class quite easily.
Yes, but that reference is getting to be a bit much to
type. We could automate Mike's method by using some
convention in the case where the user does not provide
a name, such that:
package MyApp;
use base 'CGI::Application';
use CGI::Application::Plugin::TT name =>''; # name
defined, but false
use CGI::Application::Plugin::Config::Simple name
=>'conf'; # name defined and true
use CGI::Application::Plugin::MyPlugin; # name not
defined
[snip]
$self->process(...); # TT method clobbers previous
'process' methods
my $param = $self->conf->param(..); # uses user
defined accessor name
my $self->MyPlugin->my_method(..); # 'MyPlugin'
accessor name given automatically by
UNIVERSAL::moniker or some such method for creating
unique names
> > Ok, now time for questions, comments, verbal
> abuse...
>
> Plugin modules should really only be exporting one
> or two methods each.
> In the C::A::Session module, the only really
> important method is the
> 'session' method.
I hope Mike's method will still allow for the
CGIAppPlugin attribute to specify which methods are
'exported', or, perhaps a better word is 'accessible'
- through the accessor.
> I'm glad you guys are interested in building on
> these ideas, 'cause that
> was what I was hoping for. But I am still not
> convinced that the
> namespace issue is that big of a problem.
I respectfully disagree. I think it is a fundamental
problem.
It might
> be worthwhile to
> look at other perl modules that implement plugin
> architectures for
> inspiration.
I'd probably be more inclined to look at the
strategies of mature, successful projects like apache
and jedit and perhaps even jabber. Not sure when I'll
have the time though...
Thanks for packagin up the DBI plugin though Cees and
giving us something to structure the discussion
around!
Bill
---------------------------------------------------------------------
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]
