--- 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 instances onto it and off of
it, and be accessible throughout my CGI App via the
plugin.  

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 methods the same as someone else.
  


> > Why separate the data store from the object? If
> > instance_1 and instance_2 are refs to their
> objects,
> > as opposed to a data store, that would be more in
> line
> > with regular object oriented programming.  




> > $plugin_self_instance_1->{mydata};
> >
> > you need something like:
> >
> > $plugin_self_shared->get_mydata( {instance =>
> > instance_1, data_key => mydata } );
> 
> One thing to be clear about here is that "$self" is
> always the CGI::App
> object, never a plugin-specific object. 

OK, but you still need to point the plugin method to
the right instance data.  We are decoupling objects
from their data in the name of having the method in
the $self namespace.  

To say there
> may be two
> instances of a plugin object is saying the same
> thing as saying there
> would be two instances of a CGI::Application object.
>  That means it's a
> separate application.

Understood.

> If you really need access to multiple "plug-in"
> objects of the same type
> from a CGI::Application object, then what you have
> is a not a plug-in,
> which is defined as being additional methods for the
> CGI::Application
> object.
> 
> Instead, this sounds like the case of accessing an
> other OO object.
> This already commonly happens when people access
> CGI::Session directly,
> or Data::Page, HTML::FillInForm, etc.

Yes, I see your point.

> I think the only case that applies for plug-ins,
> would be the desire to
> call the same method multiple times. I don't think
> that case needs
> special consideration, though.
> 
http://search.cpan.org/~ceeshek/CGI-Application-Session-0.03/lib/CGI/Application/Session.pm#session_config
> 
> If you need access to two different CGI::Session
> instances in the same CGI::App
> project, then the plug-in methaphor breaks down. It
> would be clearer to 
> work with CGI::Session directly in that case,
> creating two instances of the 
> CGI::Session object as usual.

Yes, perhaps plugin is the wrong metaphor.  I'm
thinking more toward writing an object cache plugin,
which I could do using you plugin structure.
 
> If a plug-in really wants to support multiple
> instances, they could
> something like Ima::DBH does:
> 
>
http://search.cpan.org/~tmtm/Ima-DBI-0.33/lib/Ima/DBI.pm
> 
> It creates extra method names on the fly, based on
> your connection parameters:
> 
>   package Foo;
>   use base 'Ima::DBI';
> 
>   # Class-wide methods.
>   Foo->set_db($db_name, $data_source, $user,
> $password);
>   $dbh = $obj->db_*;      # Where * is the name of
> the db connection.

Brain overload ... I'll trust you that it works and is
useable by normal humans. :)

Bill

> ###########
> 
>       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]
> 
> 


---------------------------------------------------------------------
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]

Reply via email to