[Seaside] 2.5 sushi store shopping cart & back button

[Nevin Pratt]

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