> 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 argue it
shouldn't do that, and this should be required:
use CGI::Application::ValidateRM (qw/check_rm/);
> Here is a restatement of our requirements from earlier
> discussion:
> 1) a separate name space for each plugin
Using Exporter, each plugin /is/ in it's own name space.
In some cases they are are exported to the caller.
With ::ValidateRM, it would have been possible to force the explicit
use of the name space by not exporting 'check_rm()' at all:
CGI::Application::ValidateRM::check_rm($self, @args);
I think the key point here is that Exporter already provides the
flexibility needed to manage name space issues. You have your own
name space or not, or export or not. Our plug-in system can determine
what's best by a convention, rather by some rule that adds additional
complexity, or doesn't suffice for an edge case. I recall a phrase from
the camel book, I believe: "I want you to stay out of my living room
because I asked you to, not because I have shot gun". We don't need shot
gun to enforce plug-in rules.
I'm /am/ in favor of separate "object space" inside of the C::A object.
> 2) plugins must be able to discover and use other
> plugins
I'm not sure what is intended here. If I want my plug-in to use another,
shouldn't be sufficient to read the docs and code and make it work? At
least with the Exporter method, it seems to me it should work to just
"use" another plug-in if I need to. This is the common "has a"
relationship that is used. Unless I'm missing something, I don't think
we need extra magic to make it work.
> 3) allow object caching by plugins
This isn't a feature that I've used before by design. Is there a pointer
someone could provide to the benefits and drawbacks of this requirement?
I have been following the related threads, but I must have missed this.
> Plugins can discover each other by looking at all
> plugins on $self->{_plugins} and check their ref
> types.
To provide a concrete example, are you talking about a case where
some plug-in might behave differently whether or not you have the
TT plug-in loaded, versus the default HTML::Template solution?
I think if we have a standard about where the plugin data is stored,
this should be solved.
Before I proposed
$self->{TT}
I like that because it's short. I think it could also be reasonable to
more verbose. This style would be consistent with the other CGI::App
internal data stores:
$self->{__PLUGINS}->{TT}
> Singleton plugins will be responsible for makeing
> themselves singletons.
I agree this is reasonable.
>> 1. Rename and refactor existing plugin modules to be
>> consistent:
>> - ::Session
>> - ::ValidateRM
>> - ::Config::Simple
>> - ::TT
To clarify, I did intend for all these to be under the ::Plugin name
space.
Mark
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark Stosberg Principal Developer
[EMAIL PROTECTED] Summersault, LLC
765-939-9301 ext 202 database driven websites
. . . . . http://www.summersault.com/ . . . . . . . .
---------------------------------------------------------------------
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]
