>From: Michael Jouravlev <[EMAIL PROTECTED]> > > On 1/24/06, Gary VanMatre wrote: > > >From: Michael Jouravlev > > > > > > 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? >
Ya, JSF merged the struts concepts of a stateless action and a statefull form bean into the concept of statefull managed beans. You can associate as many as you want with a web page. Managed beans, are also called "backing beans" - if you are in the hipster JSF crowd. JSF has an IoC container that it used to deliver managed beans. Unlike spring, you can specify a scope context that you want the object cached (application, session, request, none). So, it's the same issue you have with struts in terms of state management for a web application. But, Shale has a dialog manager that allows you to define a workflow of pages and define transition actions between pages (like struts action chaining - http://struts.apache.org/struts-shale/features-dialog-manager.html). I guess Seam is another pretty slick solution for addressing state management defined in dialogs durations using annotations. > > 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? > That's correct. This is where Shale steps up to the plate. Shale has a concept of a view controller. The view controller adds additional events to the standard JSF lifecycle (http://struts.apache.org/struts-shale/features-view-controller.html). This feature is implemented using filter. It's not JSF runtime specific and also provides a common chains (CoR) hook similar to the request processor in struts action 1.3. These hooks are usefull for doing things you might have done in struts actions. Vanilla JSF allows you to address this with dependency injection of your backing bean. > 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. Backing bean is slang for managed bean. It's fun to hear when said by the German MyFaces guys :-). Backing beans can be any POJO object. If you like how spring does this you can use Shales spring integration (http://struts.apache.org/struts-shale/features-spring-integration.html). >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? > Well, I used the term "view" model for handling the actions triggered by command buttons on the web page (baking bean) but a business model could also be a managed bean depending on the chosen architecture. > > 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 in navigation > file, and I still get the saved value. It is saved somewhere. > The submitted values are extracted by the components extending UIInput. It's very similar to how struts form bean validation works. The submitted values (String data types) are pushed to the components by invoking the renderers decode method. Components are responsible for extracting values from the request. The submitted values are used in the validation phase. The data type conversion is performed using the snap in converters. And, the Validator are invoked. If there are validation errors, the submitted values are used to rerender the view. The submitted values are pushed to the backing beans after validation. Components are bound to the "backing bean" using expression language. > > 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 ;-) > I'm not sure how to respond to that. But, I think one line of code might be the best description. <h:commandButton value="submit" action="#{backingBean.save}/> Clicking on the button invokes the save method on the managed bean "backingBean" - pretty slick. The save method is all about the business logic (functional requirements) versus the non-functional logic that associates the label of a button with logic to invoke. > > 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 ;) > The data from an input component is pushed on pulled from the managed bean, backing bean, form bean or IoC managed POJO (Whatever you want to call it). The component has state associated with it's visual asspects that is saved and resorted. This includes the EL bindings to the "backing beans". A page is assigned a view root (the top of the component tree). So, the view root is a component with children. The view id (the URI part of the request) is used to identify the components on the page starting at the view root. > Michael. > Gary > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
