On 1/24/06, Gary VanMatre <[EMAIL PROTECTED]> wrote: > >From: Michael Jouravlev <[EMAIL PROTECTED]> > > > > 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.
It describes a generic restore view + render response sequence with no regard to history list. After reading your explanation below I guess this is ok, view should not bother about history. So, it just binds to model classes and reads data from them? This means that model should have structure and content that is compatible with the page I am navigating to. If the model has changed, then view is not restored properly and an exception will be thrown, right? > 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. Yeah, I see. This was a bit of confusion. > The size of the text, > the properties of the component and what backing bean (view model) data > the component is bound to. So, a previous page requires a compatible view tree, and the view requires the compatible data model to pull data from. So to ensure that I can go back I have to ensure that I can present my data in a way that compatible with the view of an older page. You just wrote this: "what backing bean (view model) data the component is bound to". I have to provide the same structure of view model, but it is not required to have the same content? Reading JSF 1.2 spec I don't see definition of a backing bean. What is it? Does it hold buffered input or is it a BO/DTO? I guess it is not former, because if I am not mistaken JSF provides its own input buffering while backing bean is defined by me. If it is the latter, then it is not a "view model" as you called it, it is a real model with business data, which most likely have changed and I either have to roll it back or to present current data in a fashion that can be digested by a view tree of the older page, right? > 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. Really, I did not get this. If submitted values are not saved in viewstate, where they are saved? I can use <redirect/> in navigation file, and I still get the saved value. It is saved somewhere. > 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. If this is a benefit (I believe it is) then I don't get the resistance of some seasoned Struts users to Struts DispatchAction, based only on a premise that DispatchAction behaves like controller ;-) > 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. Ok, to post to a component I must have component present, which is why component is saved in a tree. The component is saved just as an object where I can post to, but it does not save its content? Or what it saves is just incorrect user input? Or input is saved somewhere else? You lost me again ;) Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
