A Seaside UI is a tree of "component" objects. You can think of them sort of like separate windows, each in their own thread, with their own state and widgets and event handlers, but all ending up renderered to the same HTML page. Each component gets a chance to stick some extra information into the URL based on its current state. Most of them don't take advantage of this, but, say, a MessageViewer might add a "messageid=23" parameter. That's half of the extra work. The other half is writing a piece of code that, when starting a new session, constructs an appropriate component tree based on the incoming request. So it would need to look at the "messageid=23", and build the UI to include a MessageViewer holding onto the appropiate message. Then it would go from there in its usual persistent-session way.

In most web environments, you end up doing this (mapping application state to and from URLs) for every page of the app. The only thing that makes it "extra" in Seaside is that most of the time Seaside lets you get away with not doing it.