Hi Simon, thx for your answer! I've added my comments inline:
> When using client-side caching, it happens automatically, because after > the user clicks "back" then submits a form, the old saved component tree > gets submitted back to the server and hence the old component tree gets > restored. > When using server-side caching, the last N component trees are stored in > the http session, where N defaults to 20 but can be configured in the > web.xml (sorry, can't remember the key). Yes, I know, I've used client side state saving for a long time... this seems to be the version with fewer problems, because as you've already said, the component tree gets encoded and sent to the client with the request... so the client has to send it to the server again on each request. That's why I've switched to server side state saving. My pages had about 100 kb or even more, and using the web application was too slow when using client side state saving. I am now using server side state saving with NUMBER_OF_VIEWS_IN_SESSION set to 1. (I think that's how the parameter is called). > The code that looks up the view is in JspViewHandlerImpl.java which > delegates to JspStateManagerImpl.java (method restoreView). For > server-side state, this clearly gets a "sequenceString" which is used to > determine which of the cached component trees to use. > HtmlResponseStateManager.getTreeStructureToRestore looks in three > *request parameters* for data: > * jsf_viewid > * jsf_tree > * jsf_tree_64 > so I would guess that these fields are automatically inserted into every > form in the html page when using server-side state saving. I can't check > this as the work I'm currently doing uses client-side state saving. Well... that sounds promising... having a viewed in each request would be fine, because then it's possible to detect these resubmitted pages... It would be possible to store the used viewids in session scope bean and then compare each submitted id with the ids already stored.... Good idea, thx.. I will look that up tomorrow.. ;) > The Shale library (shale.apache.org) provides a bunch of useful > utilities for JSF, including a <token> component that I think does this > sort of checking: > http://shale.apache.org/shale-core/tagreference.html Well... I might take a look at that too, but at the moment I don't want to add another framework... At the moment I've enough of that :D. > However there are any number of JSP tags around to do this (just > google), and I don't see why they can't be used together with JSF, ie > why a JSF-specific solution is needed. I will take a look at these... Thx, Dominik
