The rendered result depend on the values in your backing beans, except in the case of a validation error, in which case the value are those sotred in the component before validation. If your search bean are request scope, you will get an empty form (brand new search bean). If your search bean are session scope, you will get the last search you made. If your search bean is application scope, you will get the last search any user has made (and lots of troubles ^^)
The view is just an architecture of elements rendering values from back beans and performing validation. As a view is something static, i see no reason you might want to clean them. There reason for "NUMBER_OF_VIEWS_IN_SESSION" is just, i suppose, to limit memory usage. Harry Co a écrit : > You are right David. > > The NUMBER_OF_VIEWS_IN_SESSION argument is a view caching limit. > If the concerned view already exists within the > "NUMBER_OF_VIEWS_IN_SESSION" latest rendered views, it will be > restored. Here's the extract from > http://www-128.ibm.com/developerworks/java/library/j-jsf2/#N100A9 > > In the case of a /postback/ (the user returns to a page she > has previously accessed), the view corresponding to the page > already exists, so it needs only to be restored. In this case, > JSF uses the existing view's state information to reconstruct > its state. The next phase after a postback is apply request > values. > > But what happens if the view called for render is composed by "search > item" elements (text, date inputs) and a "table" for result display? > Suppose the user made a first search. Then the view has been created a > populated with the search result. > Then a second search will process like this: > _first _: restore eleder view > _second_ : clean this view > _third_ :apply new search result. > > *Is there a way to avoid restoring such views?* > > My question is a little bit far from Randhal's first request but I > think it can be a good complement. > > TIA for your suggestions. > > Harry. > > > 2006/11/6, David Delbecq <[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>: > > Hi randahl, > > I recommend you take a look at the JSF lifecycle and more > particulary at > the 'Restore view' and the 'Render response' part. > http://www-128.ibm.com/developerworks/java/library/j-jsf2/#N100A9 > > The view is a set of components. The components are read (initial > view) > with their static values and their EL values and then rendered > multiple > time. It's at render time that the 'day/night' should be evaluated. If > you have this in you page: > <myCustomComponents:backgroundColor > calor="#{dayBean.isNight?'#000000':'#FFFFFF'}/> then you are sure that > background color will always be correct as long as > dayBean.isNight() is > correct. > Randahl Fink Isaksen a écrit : > > I read that the default for NUMBER_OF_VIEWS_IN_SESSION is 20, > meaning > > that MyFaces will store the latest 20 of a client's views in the > > client's session. This made me wonder how MyFaces tells the > difference > > between the views and how MyFaces know when to reuse a view. For > > instance if you visit "/aView.jsf" in a browser how can MyFaces tell > > whether that view can be safely stored and reused later in the > session > > if you visit the same view again? > > > > Let me give an example: Let us say that the view on the address > > "/aView.jsf" uses a component which makes the background color > of the > > page white during daytime and black during the night. If I then > visit > > the view just before nightfall and receive a white page and then > > revisit the view during the same session but right after nightfall, > > what color will the view then be? I would think that if the original > > view is reused it would still be white even though it should > actually > > now have changed to black. So how can I as a developer tell MyFaces > > whether or not it is safe to store the information about the > > background color and for how long the information is valid? > > > > Has anyone found some documentation about this? > > > > Thank you > > > > Randahl > > > >
