This page (revision-1) was last changed on 30-Jul-2006 19:28 by UnknownAuthor

Only authorized users are allowed to rename pages.

Only authorized users are allowed to delete pages.

Difference between version -1 and -1

At line 1 added 19 lines

%%( background-color: #c0c0c0; border: 1px dotted black; padding: 0.2em; font-size: 200%; text-align: center)

--= OLD=--

%%

%%( background-color: #c0c0c0; text-align: center)

This page predates the release of RSF 0.6 - whilst any reasoning here is probably still roughly valid, specific descriptions of the way RSF does things are probably not valid. The page may be left here either as a historical note, and/or because it refers to a part of RSF that no longer bears this name. Read it with caution.

%%

An RSF-rendered view may be allocated one or more (globally) unique view tokens - currently a 24-character string of printable characters generated by the [EighteenIDGenerator].

At the moment, there are two (independent) tokens, the [flowtoken|FlowToken], being a unique key for any particular 'flow instance' that this view is participating in, and the [errortoken|ErrorToken], which is a key for any error state (messages and rejected user values).

Reliance on "sessions" as defining a scope for storage, whether HttpSessions or otherwise, which is upsettingly almost ubiquitous in webapps, simply does not match the model defined by the web browser tool on everyone's desktop. This browser has all sorts of affordances which it is unreasonable (although often surprisingly effective) to tell users "not to use" for certain pages, including navigating using the "back" button, bookmarking arbitrary pages indefinitely, or "forking" multiple browser windows from the same links.

Whilst many users are quite accustomed (with experience) to the sorts of disasters that can result from "misusing" their browsers, there's not really any excuse for not designing apps that are as foolproof and free of fragility as possible - RSF tries to impose the minimum burden on the programmer in helping with this task.

The view token, a string stored in the base [ViewParameters] object, is used as an index into a pool of state maintained by RSF, indexing a [TokenRequestState] object. The content and strategy behind this storage is discussed on a separate page on [State in RSF|State].

During the rendering of each page, renderer and component producer are aware of both the ''incoming'' token (that which appears in the request URL) and the ''outgoing'' token which will be rendered in outgoing links from the rendering page, and may enter state under the (some transferred from the old taken) to "get ready" for the next request arriving from the client.