Bill Catlan wrote:
>Michael Peters wrote:
>>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.
>
>
> You introduce a conflict here that would need to be reconciled. For example,
> where a method attribute says:
>
> "export 'as is' into the namespace of the module using it"
>
> and the app programmer specified:
>
> use CGI::Application::Plugin::Config::Simple name=>'conf'; # name defined and
> true
>
> who wins? What namespace does the method occupy?
My initial thoughts on the subject are don't use the plugin if you don't want it's methods 'available' or your other methods 'overridden'. If there is some strange case where you want both and the plugin designer wants a method to override your existing method then maybe you should set up some alias to that method, ie:
use CGI::Application::Plugin::TT;
#but I want to keep my old load_tmpl for some reason
sub old_load_tmpl
{ CGI::Application::load_tmpl(@_) }That seems pretty straight forward to solve the odd case where someone wants to use a plugin, but not the way the designer intended.
> That being said, I like the idea of being able to specify on a method-by-method
> basis
> a) CGIAppPlugin
> b) Override
Yeah, maybe something like a) cgiapp_plugin_available b) cgiapp_plugin_override
This would make 'available' methods part of the application available through the accessor method mentioned earlier (if the user defines a namespace) and the 'override' methods will be a part of the application object. These 'override' methods should still be accessible through the accessor as well.
What I want to avoid is creating a complicated system that will make people avoid using the plugins. Using them should be as simple as possible.
> Excellent. As I mentioned above, I think that a plugin user should be able to
> force a separate namespace though, and perhaps pass the forced reference (to the
> separate namespace) back to the plugin in case the plugin relies on its own
> method internally.
I don't think the user should be able to force an 'override' method to not be overridden. Maybe if we see the need we could allow some flag to turn off all overriding but I think doing it on a method by method basis would be too much.
> use CGI::Application::Plugin::TT name =>tt, force => { MyPluginMethod =>
> nooverride };
Maybe this... (as I said above)
use CGI::Application::Plugin::TT ( name => tt, override => 0);
we need to keep it very simple or it become too much of a hassle
to use.-- 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]
