Re: [cgiapp] Re: RFC - C::A::Plugin - abstract base class for plugins

[Michael Peters <suppressed>]

Bill Catlan wrote:

> > 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. 
I also respectfully disagree with you here Cees. While perl 
does allow you violate your namespace (and that of others)
when you deem it appropriate that's not it's behaviour by 
default. The concept of namespaces came about just for this 
kind of thing... separating methods, variables so that they 
won't override each other.
> > Michael Peters wrote:
> >
> > > Ok, some more thoughts and ideas on all of this...

> > 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.

I see Cees point here. A plugin should be able to introduce 
new methods as well as override existing ones. This happens 
with apache modules too. Some create new conf directives, 
others override existing directives with their own 
semantics. As long as the plugin documents this I think it's 
a great idea.

> > 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(..);
>
> 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.

I think the OO method is better long term.
>  
> > 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.

Right, but since the user has already given this plugin a 
namespace, putting it into $self->{_PLUGINS}->{_namespace}
would mean that no one would clobber some else's stuff. Then
the plugin would be able to store other stuff in itself.

> > 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
Initially I think I like this although I would just simplify 
it with just two options. Either it has a name, or it 
doesn't. This would decrease the likelihood of an error on 
the user's part. The third example does essentially the same 
thing as the second except the name is chosen by someone 
other than the user.

Maybe on the plugin development side we would have two 
method attributes. The first would tell the plugin that the 
method is to be exported 'as is' into the namespace of the 
module using it. The second would be available through the 
above mentioned access method.

This would give the plugin designer the ability to define 
(or redefine) both $self->tt->process and $self->load_tmpl.

> > 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 agree. One or two convencience methods and then a method 
to get at the underlying object. You don't really need more 
than that.


> 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.
Oh most definitely.

> > 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.
I also respectfully disagree (with Cees). Namespaces make 
the sharing of code much much easier and that's what we are 
trying to do with these plugins right. This is one of the 
main problems with PHP. They thought it wouldn't be a big 
issue without namespaces, but sharing of code is really 
messy in that land.

> 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!

I agree. Thanks Cees for getting the ball rolling and 
starting this discussion.

--
Michael Peters
Developer
Plus Three

---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
             http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed