--- Mark Stosberg <[EMAIL PROTECTED]> wrote:
> > 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.
oh, ic. inlining 'use' messsed me up. but yes, that
would be done at compile time and $self would have the
method.
> Using Exporter, each plugin /is/ in it's own name
> space.
> In some cases they are are exported to the caller.
right ... introducing the potential for collisions. i
think we should keep the methods in there own objects
and let the user alias a reference to the object. The
reference to the object would be under
$self->{__PLUGINS}{type}{instance}...
Plugin constructors would put it there, destructors
would destroy it.
> 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.
Yes, i see your point. But where we decide not to
override a method (not export it), how do we find the
object if we want to use it explicitly? Call it as a
class method? C::A::Plugin::Myplugin::method()? And
then have to refer to the correct instance data? Why
are we decoupling the object?
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 suppose. Its just less OO and more cumbersome.
> 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?
No. Two instances in the same environment may want
different settings. For example, an HTML::Template
object may to set a different path than another
instance. Just an example.
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]
