> >>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. [snip] As long as the plugin documents this I think
it's
> a great idea.
I see the value as well and agree that it should be documented. I also think
the plugin user should be able to force any attempted overrides into their own
namespace. Please see below.
> > 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.
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?
That being said, I like the idea of being able to specify on a method-by-method
basis
a) CGIAppPlugin
b) Override
I'm not well versed in the use of attributes, but my understanding is that any
method with a 'CGIAppPLugin' declaration will have an associated list of
attributes. Thus, I take it one attribute in the list would be 'override'.
> This would give the plugin designer the ability to define
> (or redefine) both $self->tt->process and $self->load_tmpl.
>
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. For example, what if I require (for legacy code, debugging
purposes, or otherwise) both the original method and the plugin method, but want
to use a new plugin going forward? Not sure to what extent that could be
automated.
For example:
use CGI::Application::Plugin::TT name =>tt, force => { MyPluginMethod =>
nooverride };
would allow method by method programmer control.
Maybe down the road ... but wanted to note it while I'm thinking about all of
this.
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]
