NB - this implementation is incomplete and a sample only.
Stores token state inside the navigation URL. Note that the tokenID used here
(as with clientFormTSH) is irrelevant since the state ID is implicitly
specified by the client. The state is going to come back anyway, no point
trying to specify it!
This TSH should be used with some care, since the storage it offers needs to
be scoped manually - it is essentially "immortal" unless the TSH client
cleans up properly.
Currently this TSH only knows how to store state in attributes. If you want
to store it in the trunk URL, probably safer to define a new ViewParameters.
BETWEEN a POST REPONSE and the GET RENDERING, this state is indeed stored in
the URL. However, after rendering, it is stored in a client field, as indeed
any query parameters are that expect to be submitted for a POST.
Soon we will implement ClientFormPreservationStrategy, which will keep
the information in a short-lived flow token (a la errortoken) in the gap, and
then in a client form, perhaps in some form of compressed bulk.
author: Antranig Basman (antranig@caret.cam.ac.uk) |