[Seaside] 2.5 sushi store shopping cart & back button
Nevin Pratt
nevin at bountifulbaby.com
Tue Nov 15 06:28:11 CET 2005
Avi Bryant wrote:
>
> On Nov 14, 2005, at 3:53 PM, Brent Vukmer wrote:
>
>
>> I'm using an image downloaded from seaside.st; I was playing with
>> the sushi store demo, specifically the shopping cart.
>>
>> I went to the Anago page and added 3 pieces of Anago in the shopping
>> cart, then hit the back button (so that the total went down to 2),
>> then clicked done. The main page said I had 3 pieces of Anago.
>> Shouldn't the total have changed to 2 pieces of Anago?
>>
>
> No. Ignoring your sense of what the framework does: is that what you
> would want a shopping cart to do? When I put something in my cart, I
> expect it to stay there until I explicitly remove it, regardless of
> what navigation I do. This is a choice that needs to be made
> (consciously or not) for every piece of state in a Seaside
> application - is this state basically navigational, or temporal?
> Should it backtrack or shouldn't it? That's why you have to
> explicitly register each object for backtracking with the session;
> it's just not a choice the framework can make for you. The shopping
> cart is actually the classic example I use of state that *shouldn't*
> backtrack, but in general, I tend to say that UI state should be
> backtracked and model state shouldn't.
>
> Cheers,
> Avi
>
Avi,
Have you thought about having the shopping cart one of the 'getFields'
fields of the HttpRequest? Then, regardless of the Seaside session
expiry settings, the shopping cart would not expire until the
HttpRequest expired. I think the result would be that the shopping cart
would be a bit more persistant than even the Seaside sessions are, for
the simple reason that the Seaside sessions are somewhat decoupled from
the HttpRequests right now.
I've even wondered about keeping shopping carts permanent for each
connecting IP. That would make them even more persistent and permanent
than having the shopping cart tied to cookies, and without the intrusion
that cookies has. The problem with that scheme, though, is that many
different computers can masquerade behind a single firewalled IP.
I'm wondering about a way to have a shopping cart persist and be
permanent beyond Seaside sessions, and yet still be user-specific.
Something that would allow a user to, say, come back the next day and
still see their shopping cart items, but without using cookies.
I know that the 'getFields' idea of the HttpRequest that I mention above
would not provide that level of persistence, but at least it would be
more persistent than the Seaside sessions.
Any ideas?
Nevin
More information about the Seaside
mailing list