Bill --
On 2004-08-25, Bill Catlan <wcatlan-/E1597aS9LQAvxtiuMwx3w@xxxxxxxxxxxxxxxx>
wrote:
>
>> The storage could be like:
>>
>> $self->{TT}->{instance_1}
>> $self->{TT}->{instance_2}
>>
>
> I think we're debating around the edges now.
>
> 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. Your way,
> the plugin object needs to know which instance of the
> data store belongs to it, or which it otherwise wants
> to use at a particular time. Instead of just
> referring to itself for data:
>
> $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. 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.
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.
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.
> Plus, why not let a plugin user be able to specify
> certain things upon creation, such as exporting or a
> tag or the label (ie, in your example "instance_1".)
>
> Even if we go with your "data store" approach, why not
> add one more level of indirection to allo
>
> $self->{TT}->{instance_2}{data}
> $self->{TT}->{instance_2}{export_flag}
> etc.
I think this is already covered. Take CGI::Application::Session for
example. For it be useful, unique parameters need to provided
that eventually go to the CGI::Session::new() routine.
That happens through session_config():
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.
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.
###########
Mark
--
. . . . . . . . . . . . . . . . . . . . . . . . . . .
Mark Stosberg Principal Developer
mark-WmyhgDpj2fCHT8/ATrE1yw@xxxxxxxxxxxxxxxx Summersault, LLC
765-939-9301 ext 202 database driven websites
. . . . . http://www.summersault.com/ . . . . . . . .
---------------------------------------------------------------------
Web Archive:
http://www.mail-archive.com/cgiapp-svx1JCNWaqPWzzAP45jFb16hYfS7NtTn@xxxxxxxxxxxxxxxx/
http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail:
cgiapp-unsubscribe-svx1JCNWaqPWzzAP45jFb16hYfS7NtTn@xxxxxxxxxxxxxxxx
For additional commands, e-mail:
cgiapp-help-svx1JCNWaqPWzzAP45jFb16hYfS7NtTn@xxxxxxxxxxxxxxxx
|
