> Why do we need to put things into C::A's namespace?
> I
> thought they just showed that this is a bad idea.
Hi Peter,
Thanks for your input, but let's please slow down a
second.
We are in agreement, using C::A namespace is a bad
idea in its original form.
However, semantically, we want the plugin to extend
C::A, not an app module. It's partly a psychological
argument I am making and partly a recommended object
heirarchy.
Again, I think we should solve the namespace issue
anyway so that plugins don't collide in the user's app
module - if that's the consensus solution. But let's
consider making the plugin C::A centric, since it is,
after all, a C::A plugin! :) My concern is that
otherwise, plugins that only work with certain user
modules will call themselves C::A plugins, creating a
mess and result in confusion.
> Even if we
> implement 'register-unregister' system, you're every
>
> application running cgiapp on a mod_perl server
> could be
> ruined if *one* programmer forgot to unregister his
> plugin.
> And not just til he fixes it, but until the server
> get's
> rebooted. I think that's a very bad situation to
> even allow
> to happen.
No, this is an incorrect understanding of my revised
suggestion. My revised suggestion said that the
registering would be done by an object method, not a
class method.
>
> I think the only save way to import these methods
> into any
> namespace is to put them into the app's namespace
> wich is
> using it. Anything else will cause problems.
>
> You're right, this does leave a problem with one
> plugin's
> methods overriding anothers. I can't think of a good
> way to
> solve this unless we ask that each method be
> descriptive.
> Like Cees's 'tt_process()' method (for
> CGI::Application::Template) instead of just
> 'process'.
Agreed. Not sure we want to go that way, kind of
kludgy, IMHO.
> Or we could try to introduce an intermediary
> namespace
> chosen by the user to access the methods. Maybe
> something
> like this...
>
> package MyApp;
> use base 'CGI::Application';
> use CGI::Application::Plugin::Foo qw(name =>
> foo);
>
> [snip]
>
> #call foo_stuff() that comes from C::A::P::Foo
> plugin
> $self->plugins{foo}->foo_stuff;
>
Yes; your plugins{foo} is my 'plugin_token'. The
plugin can be referenced by the user's app module at
compile time or by C::A through object methods at
runtime either explicitly, by "under the hood" by
reading a known config file or ENV variable. Note:
mod_perl sets ENV variables on a per-virtual-host
basis.
> I don't particularly like that idea since it makes
> it more
> complicated, but at least it would solve namespace
> collisions cause the user using the plugin could
> name it
> whatever he wants.
>
Yeah, not sure I'm thrilled about it either - but we
don't want to setup a situation that invites namespace
collisions.
>
> --
> Michael Peters
> Developer
> Plus Three, LP
>
>
---------------------------------------------------------------------
Web Archive: http://www.mail-archive.com/cgiapp@xxxxxxxxxxxxxxxxx/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: cgiapp-unsubscribe@xxxxxxxxxxxxxxxxx
For additional commands, e-mail: cgiapp-help@xxxxxxxxxxxxxxxxx
|
