Michael, I like your solution to the namespace issue. In fact, I like it a lot!
The plugins could be brought in either in the user's app (for now) or at the config level by C::A (perhaps later). Hopefully Cees and others agree! Also, I think this would be enhanced by Lance Brown's technique as well: > you can create a C::A::MyBase package that pulls in your standard > set of plugins and then inherit all your apps from that. :-) Minimal > extra programmer step. > > --[Lance] Would that work? Would the plugin's accessor method be properly inherited by the child class? Bill ----- Original Message ----- From: "Michael Peters" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Saturday, August 07, 2004 7:57 AM Subject: Re: [cgiapp] Re: RFC - C::A::Plugin - abstract base class for plugins > 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? > > Ok, some more thoughts and ideas on all of this... > > Right now in the existing, alpha plugins, they do something > like this to avoid namespace issues.... > > package MyApp; > use base 'CGI::Application'; > use CGI::Application::Plugin::TT; > use CGI::Application::Plugin::Config::Simple; > > [snip] > $self->tt_process(...); > my $param = $self->config_param(..); > > The problems with this is that when you create a plugin you > have to make sure that you don't export a method that any > other existing plugin could export. This would be a > headache. Not to mention that if you're plugin wants to try > and have some sort of parameters that it saves somewhere > you'll have to break the encapsulation of the the C::A > application module and try to put something in it's internal > hash. Lot's of problems with this... > > 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 one method that we export could even implement an > object cache. If it's called the first time it will call the > plugin's new() method and store the object in some agreed > upon place. Then the next time it is called it would just > retrieve that object. > > 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. > > Ok, now time for questions, comments, verbal abuse... > > -- > Michael Peters > Developer > Plus Three, LP > > > --------------------------------------------------------------------- > 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] > --------------------------------------------------------------------- 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]
