On 2004-08-25, Bill Catlan [EMAIL PROTECTED] wrote:
It just adds a research layer for plugin developers if
they wanted to be duly diligent about not naming their
exported methods the same as someone else.
I would suspect that research like this would be done as the author
searched for prior
I think the simplest solution for plugins to work
like C::A::ValidateRM
does. I don't think the proposed base class really
Mark-
I think I prefer your suggestion of using the standard
export technique - although I still firmly believe
that separate namespaces are essential.
However, I'm
Bill Catlan wrote:
I think the simplest solution for plugins to work
like C::A::ValidateRM
does. I don't think the proposed base class really
Mark-
I think I prefer your suggestion of using the standard
export technique - although I still firmly believe
that separate namespaces are essential.
Michael,
1) I'm now leaning in the direction of not needing a
separate
namespace for each plugin as long as each plugin
will have a store
in the application object. This would be solved by
the suggestion
that a plugin for incorporating 'Foo::Bar' would use
$self-{'Foo::Bar'}.
Maybe if
However, I'm unclear on how Exporter works in an
object oriented context. How does check_rm get into
the $self object below?
Simple. check_rm() expects $self to be an object that has the same
properties as a CGI::Application object.
::ValidateRM is exporting check_rm() by default. One could
On 2004-08-25, Bill Catlan [EMAIL PROTECTED] wrote:
Naming the plugin storage space with user provided
tags allows more than one instance of a plugin object.
Multiple database init plugin objects, or template
initialization plugin objects with different
parameterization come to mind.
What
Bill --
On 2004-08-25, Bill Catlan [EMAIL PROTECTED] wrote:
The storage could be like:
$self-{TT}-{instance_1}
$self-{TT}-{instance_2}
I think we're debating around the edges now.
Why separate the data store from the object? If
instance_1 and instance_2 are refs to their objects,
--- Mark Stosberg [EMAIL PROTECTED] wrote:
Thanks Mark ... I see your points and I think I'm
coming around.
I think what I would want to do then is implement a
plugin that holds an object cache or what I think java
calls a vector or collection. My cache would allow me
to push and pop object
Bill Catlan wrote:
I am still a bit troubled by perl's Exporter, and
conflicting methods being exported, but I guess that
can be managed somehow, without a shotgun. :)
It just adds a research layer for plugin developers if
they wanted to be duly diligent about not naming their
exported
Cees --
On 2004-07-27, Cees Hek [EMAIL PROTECTED] wrote:
It's been fairly quiet on the development side of things with
CGI::Application, so I thought I would try to stir things up again ;)
A little while ago, I noticed some talk on the Class::DBI list about a
plugin architecture for
Cees Hek wrote:
Bill Catlan wrote:
Plus, I think most plugin methods will /not/ seek to
override existing methods, and will be of the
cgiapp_plugin_available type. I think, where a name
is not provided by the user, it is more consistent and
intutitive that those methods would be put in a
--- Michael Peters [EMAIL PROTECTED] wrote:
Cees Hek wrote:
What is the difference between the plugin choosing
a default namespace
(and importing a method to access that namespace
into the caller), and
importing one or two methods directly into the
caller?
The difference is that
'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
Bill Catlan wrote:
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.
My intial thought would be to
--- Michael Peters [EMAIL PROTECTED] wrote:
Bill Catlan wrote:
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
Bill Catlan wrote:
As long as some thought is put into writing the
plugins, I don't really
see a big problem here.
Yes and no. Thought is one thing, but having to
research the plugin methods exported by all /known/
plugins is another. As plugins proliferate, like we
hope, what a chore that
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...
On Sun, 8 Aug 2004 12:23:05 -0400, Bill Catlan wrote:
Hi Folks
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
On Thu, 05 Aug 2004 16:59:50 -0400, Cees Hek wrote:
Hi Cess
sub auth : CGIAppPluginMethod {
my $self = shift;
# do some cool stuff
}
sub _private_auth {
# so some more cool stuff
}
In this case the 'auth' method would be exported and made
available, but
the _private_auth method would
Bill Catlan wrote:
Just to set a reference point, do we all agree that
everything we discussed would benefit from some agreed
upon method of preventing namespace conflicts between
plugins - no matter what space they are brought into?
Ok, some more thoughts and ideas on all of this...
Right now in
- Original Message -
From: Michael Peters [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Sent: Saturday, August 07, 2004 7:57 AM
Subject: Re: [cgiapp] Re: RFC - C::A::Plugin - abstract base class for plugins
Bill Catlan wrote:
Just to set a reference point, do we all agree that
everything we discussed
Bill Catlan wrote:
Michael,
I like your solution to the namespace issue. In fact, I like it a lot!
The plugins could be brought in either in the user's app (for now) or at the
config level by C::A (perhaps later).
Hopefully Cees and others agree!
Also, I think this would be enhanced by Lance
Thanks for spending some time on this guys. I appreciate the help and
support.
Bill Catlan wrote:
Just to set a reference point, do we all agree that
everything we discussed would benefit from some agreed
upon method of preventing namespace conflicts between
plugins - no matter what space they
Bill Catlan wrote:
Just to set a reference point, do we all agree
that
everything we discussed would benefit from some
agreed
upon method of preventing namespace conflicts
between
plugins - no matter what space they are brought
into?
I think it is very worthwhile notifying the
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
It simplifies and standardizes the way a plugin can be built for
CGI::Application, and it works completely outside of the
CGI::Application codebase (ie no patches necesary). It avoids the
annoyances of building a big inheritance tree for the plugins you want
to use by copying a given set
Mark Stosberg wrote:
It simplifies and standardizes the way a plugin can be built for
CGI::Application, and it works completely outside of the
CGI::Application codebase (ie no patches necesary). It avoids the
annoyances of building a big inheritance tree for the plugins you want
to use by
Answering for Cees (hope you don't mind :)
Bill Catlan wrote:
Cees,
So a plugin author would
use base CGI::Application::Plugin;
in their plugin, and that would be it?
And they would have to add the CGIAppPluginMethod attribute
to the methods they want the user to have access to. Just
like this:
Bill Catlan wrote:
Cees,
So a plugin author would
use base CGI::Application::Plugin;
in their plugin, and that would be it?
That is the first part, the second part is to mark which methods you
want automatically exported to the class that is 'use'ing the plugin,
and that is done using a
Sounds good ... did someone previously mention that an
initial hack is available? :)
Bill
--- Michael Peters [EMAIL PROTECTED] wrote:
Answering for Cees (hope you don't mind :)
Bill Catlan wrote:
Cees,
So a plugin author would
use base CGI::Application::Plugin;
in their
Cees Hek wrote:
Bill Catlan wrote:
Sounds good ... did someone previously mention that an
initial hack is available? :)
http://cees.crtconsulting.ca/perl/modules/CGI-Application-Plugin-0.01.tar.gz
Or if you just want to look at the code:
40 matches
Mail list logo
