Thanks Cees. That all looks great. I have a thought
on the conceptual level though. Please note, I am
half thinking out loud here - just interested in
others' thoughts.
Should C::A::Plugin perhaps put the plugin methods
into C::A space, and not the C::A app module? After
all, the plugin is a
On August 6, 2004 7:10 am, Bill Catlan wrote:
Thanks Cees. That all looks great. I have a thought
on the conceptual level though. Please note, I am
half thinking out loud here - just interested in
others' thoughts.
Should C::A::Plugin perhaps put the plugin methods
into C::A space, and
Quoting Bill Catlan [EMAIL PROTECTED]:
Should C::A::Plugin perhaps put the plugin methods
into C::A space, and not the C::A app module? After
all, the plugin is a /C::A/ plugin, not a 'MyApp'
plugin.
Hi Bill,
That is how the C::A::Session module currently does it. But there are some
--- Cees Hek [EMAIL PROTECTED] wrote:
Quoting Bill Catlan [EMAIL PROTECTED]:
Should C::A::Plugin perhaps put the plugin methods
into C::A space, and not the C::A app module?
After
all, the plugin is a /C::A/ plugin, not a 'MyApp'
plugin.
Hi Bill,
That is how the C::A::Session
Bill Catlan wrote:
Hi Cees,
Thank you for the thorough response. I thought of the
problem you mention, but not so much from the rug
being pulled out from under you in mod_perl angle.
Still, the issue is the same - namespace collision.
I'm not sure I can propose the best solution without
some
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
--- Brett Sanger [EMAIL PROTECTED] wrote:
On Fri, Aug 06, 2004 at 12:27:18PM -0700, Bill
Catlan wrote:
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.
Okay,
Bill Catlan wrote:
Fair enough. I just think using the app modules
namespace for a C::A plugin is not as clean and adds a
programmer step for every module. I probably will
want some plugins available across my modules - why
should I have to bring them in in every module? Let
C::A do it.
Or you
Or 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.
That is true. I guess I just think plugins are a
configuration level issue. Strikes me as odd to write
a class to use plugins.
Bill Catlan wrote:
Or 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.
That is true. I guess I just think plugins are a
configuration level issue. Strikes me as odd to write
a class
10 matches
Mail list logo
