The backing bean are one part of the model what is often called the data model in the Swing world. It is a combinaison of Struts DispatchAction and ActionForm concepts. It exposes your business logic layer via DTOs or regular BOs depending of your architecture. You can refer to them as ViewHelper in the pattern world.
The components local values is the other part of the model what is called is the Swing world the GUI model, for instance it holds the color value, the current selected element, ... I think there is no equivalent of this concept in Struts unless you add some custom fields to your ActionForm (not binded to any form input values) but I could be wrong. Together they form the M in the MVC. Well I hopes it's clear things up. Feel free to correct me if I'm wrong. On 1/25/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > 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] > > -- Alexandre Poitras Québec, Canada --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
