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 you could think of a case where separate
> namespaces for
> plugins would be essential it would help.
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.
> Also, if we use Mark's idea of simply using Exporter
> then the user
> can still turn off methods he doesn't want to use,
> just like with
> any other module using Exporter. So if you override
> 'load_tmpl' in
> you plugin but the user doesn't want it to override
> his method, but
> still wants to use other methods that your plugin
> provides, it's
> very easy to do.
Again, not clear on how this works in an object
oriented context.
> 2) If we follow the naming convention repeated
> above, this would
> solve it. If an auth plugin wanted to access a
> 'Session' plugin,
> then he could use $self->{'Session'} or
> $self->session.
Assuming only one plugin instance is desired.
> 3) Once again, this is solved by the above.
>
> > I think the solution I'm going to try implementing
> > looks like this:
> >
> > In C::A::MyApp or C::A::AppBase:
> >
> > use C::A::Plugin::MyPlugin( name => myname,
> exported
> > => 0|1 );
> >
> > Here, name attribute (UID) is optional, and a
> > universally unique name (UID) will be provided by
> > default.
> >
> > Here's what will happen:
> >
> > $self is a C::A object or child thereof.
> >
> > $self->{_plugins}{UID}{ ref => $plugin_object,
> > exported => 0|1 ...}
> >
> > Where exported equals 1, exported methods will be
> > available as follows:
> >
> > $self->pub_method;
> >
> > Plugins can discover each other by looking at all
> > plugins on $self->{_plugins} and check their ref
> > types.
> >
> > Singleton plugins will be responsible for makeing
> > themselves singletons.
> >
> > Plugin authors will inherit from base class
> > C::A::Plugin which will provide exporting
> functions
> > and a DESTROY method that will keep
> $self->{_plugins}
> > synchronized with plugin object destruction. If
> this
> > synchronizing method is problematic, the 'ref'
> hash
> > key above might be replaced with a 'idtag' (random
> ID
> > number) and 'type' (C::A::Plugin::MyPlugin)
> attributes
> > which will be deleted when the associated plugin
> > object is destroyed. (I've heard of linking these
> > kinds of things with tie, but I don't want to use
> > tie.)
>
> Just seems too complicated for such a simple issue.
> But maybe that's
> just me.
Its flexible and powerful and simple. I don't see
where the complexity is for you. Both parameters are
optional, and the haah struture allows future params
which will surely be desired.
> >>helps this. It just
> >>does the exporting in a different way. It uses
> >>attributes to do this,
> >>which are less well known than the standard EXPORT
> >>method.
> >>
> >>I don't think it's too much of ask of plugin
> writers
> >>to use standard
> >>Exporter techniques-- export public routines and
> >>hide private ones.
>
> I'm starting to agree with Mark here.
>
> >>I propose the following alternate solution.
> >>
> >>1. Rename and refactor existing plugin modules to
> be
> >>consistent:
> >> - ::Session
> >> - ::ValidateRM
> >> - ::Config::Simple
> >> - ::TT
> >
> >
> > Sounds good.
> >
> > Thoughts?
>
> I still think we should put 'Plugin' in the object's
> name. There are
> many modules out there that split their work up into
> several classes
> that are a part of the same distribution. All of
> these helper
> classes exist under the same namespace as the
> original (Class::DBI
> has Class::DBI::Column, Class::DBI::Iterator,
> Class::DBI::Relationship, etc and TT does the same
> thing).
>
> I think it might be misleading to have these plugin
> directly under
> the CGI::Application namespace since they aren't
> used by C::A but by
> the user. By putting them in a Plugin namespace then
> there is no
> confusion. This is also what Class::DBI and TT do
> and they are very
> successful in attracting users.
> >>2. Simply update the POD of CGI::Application to
> >>explain what's going on,
> >>both for users and writers of plugins. Something
> >>like this:
> >>
> >>=head1 PLUG-INS
> >>
> >>CGI::Application has a plug-in architecture that
> is
> >>easy to use and easy
> >>to develop new plug-ins for.
> >>
> >>=head2 Existing plug-ins
> >>
> >>Here are some plug-ins that have already been
> >>developed for
> >>CGI::Application. For a current complete list,
> >>please consult CPAN:
> >>
> >>
> >
> >
>
http://search.cpan.org/search?query=Class%3A%3ADBI%3A%3APlugin&mode=module
> >
>
=== message truncated ===
---------------------------------------------------------------------
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]
