>From: Michael Jouravlev <[EMAIL PROTECTED]> > > Seems that JSF-related flame on TSS > http://www.theserverside.com/news/thread.tss?thread_id=38601 died, and > I have left without an anwser ;-) So I am repeating the question here > with some modifications in hope to get "i" dotted and "t" crossed. >
I heard all the noise even from my side of town :--) > The question is: how history lists and in particular Back button, is > supported in JSF, including: > > * JSF spec > * JSF reference implementation > * MyFaces > * Shale > * Other > > I searched Net just a bit, and found indications that Back button > issues regarding component state are resolved in 1.2 spec: > http://weblogs.java.net/blog/edburns/archive/2005/08/javaserver_face_3.html > > I downloaded spec and glanced across but did not find the answers. > Granted, I did not read it thoroughly. If the answers are there just > tell me so, if you can point to specific sections that would be great. > JSF 1.2 spec does not contain expressions "back button" or "history". > The official HTTP term for browser page history is "history list". > I think this is covered under 2.2.1 restore view. > The spec reads that if request is not a postback, a response should be > rendered (using current state, right?). If request is a postback, then > viewsate should be restored. Depending on using > instruction in config file, both cases are possible when clicking Back > button unless renderkit uses some sort of token and detects that the > received POST request is actually a resubmit of old data and should > not be considered as postback. > The code that I've looked at in this area (cool thing about open source) and the understanding I have is that the view handler asks the state manager to restore a view's component tree by view id. If you are using client side state saving, state is most likely in the request (if you are posting a dirty page); otherwise, it's cached in the session. It seems that the RI caches more server side view state than myfaces (out of the box). I believe that all GET requests result in a new component tree being created. If the state can not be restored, the view is created again by jumping to the render response phase. I think the confusion that many have is that the view state is generally not the model state but the state of the visual components. The size of the text, the properties of the component and what backing bean (view model) data the component is bound to. The components do hold the submitted values but this data is not saved in the views state. This is how JSF allows binding to native data types versus only String types - the buffer before converting to the view model\ backing bean. Components can hold static text but the verbatim component is transient and doesn't save state. I think of the struts lookup dispatch action when thinking about how JSF handles the view state. The dispatch action you have some strategy for mapping what command was invoked from the action. Based on some strategy, you determine what logic to invoke to handle the command or the view to render. In JSF, the visual components handle decoding the data versus a single action controller. So the components are more like small individual controllers. The view state contains a tree of the components on the page. This is why the restore view is needed for handling a post of the page. When using the lookup dispatch action, you have to determine if you need to load data staging for the view or responding to a command that was invoked. Restoring the state of the view in JSF is the same kind of strategy but it would be like grafting together a command chain that also contained the characteristics of the visual widgets. Gary > > Michael J. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
