Thanks for spending some time on this guys. I appreciate the help and support.
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.
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...
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.
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.
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. There is another method to allow for preconfiguring the object as well, but it is only called once (and perhaps we can come up with a beter way of initializing the plugins). I went a little bit overboard in the Template Toolkit plugin, to make it gel with the programming structure that CGI::Application builders are used to. But again the only really important method it exports is 'process' which renders the template for you.
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. It might be worthwhile to look at other perl modules that implement plugin architectures for inspiration. I used Class::DBI::Plugin when building this module (I'll state again that I didn't really write CGI::Application::Plugin, as I pulled most of it from Class::DBI::Plugin).
Cheers,
Cees
--------------------------------------------------------------------- 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]
