[Seaside] Where to put a shopping cart

Avi Bryant avi at beta4.com
Tue Mar 25 13:24:15 CET 2003


On Tue, 25 Mar 2003, Nevin Pratt wrote:

> I'm struggling a bit in deciding the best place to store an instance of
> my ShoppingCart class.
>
> For a "normal" web app, I would store it as an attribute of the
> HttpSession.  However, Seaside's notion of a Session is a bit different.

Not really.  It's different only because, as you point out below, you're
splitting one conceptual application into multiple seaside applications.
I wouldn't recommend doing this, and there's no real need to.  Look at the
Wiki example - it maintains a single session but each wiki page you visit
is bookmarkable.

How this is done varies slightly between Seaside 2.2 and 2.3.  In both
cases, you can send the #path: message to your Session at any time, and
this will effectively set the current url.  If someone bookmarks and
returns to this url after the current session has expired, in 2.2 you will
end up in Session>>unknownRequest:.  You can then examine the path and
choose an appropiate entry point.  In the current CVS version of 2.3,
there is an explicit #createRoot method on Session that you can override
that makes this process a little simpler, but the theory is the same.

(One thing that's a little awkward about doing this in 2.2 is that you
have to set #path: before you call a component, rather than having a
component be able to set its own #path:.  2.3 more or less solves this.)

Once everything's in the same session, you can either use the
#topComponent scheme you describe (which I've used as well), or put the
cart in your session subclass (which is probably easier as every component
has easy access to the current session).

The other advantage of doing things this way is that you never need those
coarse grained jumps between applications - setting #path: is just an
approximation of the current state should someone need to return to this
point after the session is expired, but while the session is alive you get
better state transfer between the different sections of your app.

Alternatively, there's nothing to stop you from storing a cookie with a
shopping cart id and keeping a global dictionary of carts, and then using
shorter lived Seaside sessions as you do know.  But that really shouldn't
be necessary.

Avi



More information about the Seaside mailing list