> '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(@_) }
I agree, that is sufficient. I also agree that its
best to keep things simple for the plugin user.
I think accommodating legacy code is important though,
but the above technique should be able to facilitate a
workable solution to someone stuck supporing legacy
code. Hopefully, plugin authors will maintain
backwards compatibility for any overridden methods.
> > 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.
Where a user does not specify a name space, where do
the methods go - a default namespace, or the module's
namespace? I think, based upon what we said earlier,
it would be a default namespace - perhaps given by
UNIVERSAL::moniker - or whatever.
> 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.
I'm fine with that.
> > 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);
Yes, default behavior for
use CGI::Application::Plugin::TT
being:
use CGI::Application::Plugin::TT ( name =>
[moniker], override => 1 );
Correct? Any ETA on when you see yourself getting to
this?
By the way, I did some research on attributes, but
never worked with them; I think you might want to
consider having only one attribute name (eg,
cgiapp_plugin) and you then define an attribuite list
for each subroutine with that attribute name. Either
that, or you can parameterize the attribute. I think
by doing so, you can swap out the attribute list from
underneath the attribute name and alter program
behavior - by using differing default attribute list
values, for example. Just some (half baked) thoughts.
:) If this is all correct, I think it becomes trivial
to flip attr list values on individual methods if we
ever want to extend the API. For now, we would do it
wholesale, as you suggest, setting the 'override' attr
list value to whatever the 'override' param provides,
or according to the rules we've discussed.
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]
