[Seaside] Where to put user state (was: Re-render component on back button)

Lorenz Köhl lorenz at quub.de
Wed Dec 4 01:29:21 UTC 2013

On Dec 2, 2013, at 9:33 AM, Diego Lont <diego.lont at delware.nl> wrote:
>  If you want it to persist, then you have to store it somewhere else. For instance, you could make a shopping cart cache belonging to the user. And if it is a guest user, than you make some temp user, that is removed after a certain time.

Where to put user and view state can become quite confusing indeed. I got sidetracked building this user abstraction, but have now settled on application specific WASession classes which search for an agent/user and create it if  necessary. An agent has a #state: method where index the models by class, eg.

	agent state: MyShoppingCartModel

and the model is lazily initialized. In components I can thus do:

	(self session agent state: MyShoppingCartModel) add: self product

The #state: method also injects the agent's announcer (each agent announces its activites) on each model.
A model then announces a change, eg. MyShopAddedItemToCardEvent.

The agents events are also re-announced (think 'retweeted') in the session so that components may react.

	MySession >>#initialize
		agent announcer on: Announcement do: [ :ann | self announcer announce: ann ].

It's a bit involved (two announcers, models must accept announcers), however I think this way the state is nicely decoupled from seaside specifics, so writing a morphic gui that monitors the shop should be easy.

What do you folks think, over-engineered? How did you solve this?

By using announcements for everything on the page you get a built-in analytics engine with the little more effort to store them in an event DB. Maybe this could be used for automated split-testing…

Has anyone here done split tests with seaside?

> Also in production you probably have a web server between your seaside and the net, and I usually configure it here.

Do you rewrite all caching for seaside interaction? Or is there scheme as to what should be cached? (eg. /files should be served with caching). But in general, all requests with callbacks involved shouldn't be cached, right?



More information about the seaside mailing list