Nicu's solution works fine for MyFaces commandLinks using the MyFaces JspStateManager. Someone using MyFaces Tomahawk can take advantage out of this new view pool approach.
The big problem here: It does not work using a component library that decorates the statemanager (eg. trinidad). So far I did not take a look to trinidad's statesaving mechanism. It'll be worth to think about a more common solution for having a state view pool. -Thomas On Dec 20, 2007 9:41 AM, Simon Kitching <[EMAIL PROTECTED]> wrote: > Orchestra provides a tag that can be explicitly wrapped around links (eg > h:outputLink). It then encodes a "window id" into the url params. > > So it also partially addresses the second part of the problem (identifying > windows/frames). It covers more cases than Nicu's suggestion, but it does > require modifications to pages. > > Orchestra then uses this window-id to provide a new set of > conversation-scoped beans per window. But nothing in orchestra addresses the > problem of the view-state pool, so unless I misunderstand something this > Orchestra feature is not really usable; the backing beans will work right but > when the viewstate gets screwed up after 4 page-views that is no consolation. > > I think myfaces core needs to provide a per-window viewstate cache. It can > then just allow something else to figure out how to identify the windows, > allowing the Orchestra approach or Nicu's approach, or whatever people come > up with. > > Yes, it would be interesting to hear how Trinidad dialogs handle this.. > > Regards, > > Simon > > ---- Martin Marinschek <[EMAIL PROTECTED]> schrieb: > > > Hi Nicu, > > > > we should include Mario in this discussion - he implemented a solution > > for this in Orchestra. Also, how about Trinidad, in Trinidad there is > > dialog handling as well, how is this done? > > > > regards, > > > > Martin > > > > On 12/19/07, simon <[EMAIL PROTECTED]> wrote: > > > Hi Nicu, > > > > > > I haven't got time to look at this closely, but IMO siomething like this > > > is definitely needed in MyFaces. A user with multiple windows is > > > certainly going to have trouble at the moment. > > > > > > I think a modification to the view pool to include a "window id" (or > > > "frame id") is definitely a good idea. > > > > > > The second part of the problem still remains: how to associate a > > > different id with each window/frame. Checking CommandLink components for > > > a "target" attribute is clever; it doesn't solve all the cases but does > > > solve some. > > > > > > Regards, > > > > > > Simon > > > > > > On Tue, 2007-12-18 at 19:07 +0200, Nicu Mercioiu wrote: > > > > Hi, > > > > > > > > There is a problem in JSF when more than one window are opened > > > > in an application. > > > > There are only a maximum number of NUMBER_OF_VIEWS_IN_SESSION view > > > > states saved at one moment (when server side state saving is enabled). > > > > If you have 2 windows opened and you navigate on one of them for > > > > NUMBER_OF_VIEWS_IN_SESSION times, you will lose the other window's > > > > state. > > > > > > > > I've been facing this problem while developing a project so I've > > > > implemented a solution for it. > > > > > > > > The solution is having a number of view states saved for each > > > > opened window at one moment. > > > > For determining when a new window (frame) is opened, the target of the > > > > submitting component (or its enclosing form) is used. > > > > This is obtained in the HtmlLinkRendererBase's and > > > > HtmlButtonRendererBase's decode methods and it is set in the > > > > RequestMap. > > > > Using the "submitted" target, the JspStateManagerImpl figures out > > > > whether a new frame was opened. > > > > If so, a new frame id is generated. > > > > In the renderResponse phase, the frameId is encoded in the > > > > javax.faces.ViewState field > > > > and is used along with the viewId to save the state in a > > > > SerializedViewCollection. > > > > In the restore view phase the frameId is decoded from the > > > > javax.faces.ViewState field > > > > and is used along with the viewId to restore the corresponding state > > > > from the SerializedViewCollection. > > > > > > > > In SerializedViewCollection instead of a list of recently used > > > > views, now a list is kept for each frameId. > > > > The following context params are defined for configuring this. > > > > NUMBER_OF_FRAMES_IN_SESSION (max frames stored) > > > > NUMBER_OF_VIEWS_IN_FRAME (max views stored per frame) > > > > These replace the old: NUMBER_OF_VIEWS_IN_SESSION context-param. > > > > > > > > > > > > What is your opinion on this solution? > > > > > > > > Of course this solution only works with MyFaces Tomahawk's > > > > commandLink and commandButton. > > > > Ohter component sets that do not use a custom stateManager might use > > > > this feature > > > > if they will just modify the renderers of command components to set > > > > the target attribute in the requestMap. > > > > > > > > An extra feature would be to enable this for outputLinks (plain > > > > old links) and for JS (openWindow). > > > > The solution for this is quite simple, just add a GET parameter named > > > > 'target' and set the value the same as the target attribute. > > > > In the JspStateManagerImpl this value is obtained from the > > > > requestParameterMap and used the same as in the other case. > > > > Do you think this would be useful too? > > > > > > > > Regards, > > > > Nicu > > > > > > > > > > > > -- > > > > http://www.irian.at > > > > Your JSF powerhouse - > > JSF Consulting, Development and > > Courses in English and German > > > > Professional Support for Apache MyFaces > > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
