kropotkin wrote:
Hi Steven

Not quite. From the catalogue I want to see what is in the user's cart. As
they browse the catalogue they will see a  flag next to each item if it is
in the basket; 'n already in your basket' sort of thing.

So from the class which produces catalogue pages I want to be able to obtain
information about the contents of this user's basket. You may say,
instantiate the basket class from the catalogue class and in many ways this
seems the simplest. I haven't done this because the both classes are part of
a framework. Basket does not have a constructor of its own but a method
which constructs it as part of the framework - I think what I probably need
is to create a new class which both these can use.
I don't think you need a delegator.

Store the 'global' cart (which is part of the user which is part of the session) in the execution environment/scope.

The catalog code might say

GLOBALREQUEST->current_session->current_user->current_cart->is_in_cart('thisitem')

I have encountered this 'back call into execution context' a few times. Generally to me this means you have a singleton pattern.

In a short concise code expression:

package Cart;
my $instance;
sub new { return $instance ||= bless {}, $self }
sub is_in_cart { ... }

package Catalog;
sub show_flag {
   my $self = shift;
   Cart->new->is_in_cart(shift);
}

The function new on Cart returns any already created instance if it exists and creates a new one if not. The package Catalog merely calls Cart->new when it wants a Cart, without having to worry about whether or not there is an instance of it yet or not (Cart class's problem) - since the same instance is returned on every call to new, that makes the Cart a singleton. It can be accessed from anywhere in the interpreter that has access to the Cart namespace by a static call to Cart->new

This lets you do things like lazy-create a cart object only when needed, and if there can't be a cart object for whatever reason you can use the Nothing/Null pattern - return an object that, to its interface, looks like a cart (same methods) but putting something into it is a noop and getting its list of contents is always an empty set... thus avoiding constantly checking to see if the object is not available in your code.

I'm babbling aren't I.

David

Reply via email to