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
