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
default namespace, not the module's namespace. This
further differentiates the cgiapp_plugin_available
attribute from the cgiapp_plugin_override attribute -
which I think makes sense.
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?
I appreciate the effort and thought you have put into this, but I honestly think you guys are complicating a very simple process. Now I wouldn't consider myself an expert on these matters, and would appreciate some more input from others on the list, but I like the simplicity of how C::A::ValidateRM and C::A::Session work right now...
That was actually one of my fears; that we were making this too complicated. I agree that simplicity is the key.
What I am looking for in a plugin is commonly refered to as a Decorator Pattern, where you take an existing class or object, and decorate it with more functionality (that is probably an oversimplification, but it should serve the purpose).
I want my Base class to have more functionality, without having to cut and paste a bunch of code all over the place. when I use the C::A::Session plugin I know that anywhere in my app I can call $self->session and I get my session object.
Agreed.
If we start importing different plugins into different namespaces, we just complicate the system, and make it more difficult to use (and to share code between developers).
Say for example I write a plugin called C::A::Auth which is an authentication plugin. This module depends on C::A::Session. So the Auth module will need to know how to access the Session object. The Auth module should be able to 'use C::A::Session' and then call $self->session to access the session object (which will always give it the same session instance that the rest of the app uses). It could also call $self->query to get the login and password from a form if need be.
If we start playing with namespaces, this situation becomes much more complicated. The Auth module will not be able to load the Session module by itself, because it may already be loaded into an unknown namespace in another location in the App. If it loads it into its own custom namespace, then any session objects that are created will not be shared with the rest of the app, and we get 2 sessions objects for a single request. So we have to leave it up to the developer to pass the namespace info about the Session to the Auth module when they use it. To me that is unnecesary complexity.
That's a very valid example. I hadn't thought of plugins using other plugins, but it makes perfect sense. We want to be able to use plugin2 without telling it a namespace for plugin1.
Lets look at namespaces from a different angle. Say in your application you want to debug some code by printing out the contents of some variables. A common thing to do is load Data::Dumper, and you have access to the 'Dumper' function to dump your data structures into human readable form. By default the 'Dumper' function is imported into the callers namespace when the Data::Dumper module is 'use'd. Is this inherently bad? Is this a dangerous thing to do? I don't think it is. This is how perl works, and it is how developers expect perl to work. I don't think the plugin system is that different. The main difference is that we are talking about methods instead of functions, but I don't think it is a very big leap to get there.
I do think there is a big difference here between subs and methods...The object stored. Most plugins will want to have some sort of an object cache so that any objects used in the back ground (TT, or CGI::Session or Config::Simple) don't get recreated on every method invocation.
The main reason I thought we needed to solve the namespace issue was so that we don't clobber stuff that's being stored inside of C::A (in the application object's internal hash) since this is where each of the currently available plugins puts stuff.
Maybe it could be as simple as a naming convention that is respected by C::A and every other plugin. If we reserve and element of that internal hash (say $self->{_Plugins}) and each plugin uses an element of that has (say $self->{_Plugins}->{'Config::Simple'} for my C::A::P::Config::Simple plugin) then no one would ever overrite someone else's data. We would also have to ask Jesse to not use the '_Plugins' internal hash for C::A.
I don't think we can use $self->{_Plugins}->{moniker} using UNIVERSAL::moniker (like we've said before) since someone could write a plugin for Config::Simple and CGI::Simple that should be able to coexist.
This would also allow other plugins to not only access the methods of other plugins, but the objects directly. So you Auth plugin could use $self->session or $self0->{_Plugins}->{'CGI::Session'}
I hope that's a little better on the simple side.
I won't have much time in the next little while to work on this stuff, so feel free to continue on and refine, and even implement your ideas. It might make things clearer to actually see an implementation of your system to see how it will work in practice.
Let me know what you (and everyone else on this list) thinks of the above ideas and then I'll try and take a crack at it in the next few days.
-- Michael Peters Developer Plus Three, LP
--------------------------------------------------------------------- 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]
