Yes, well, with Trinidad the suggested changes won't work - but Trinidad has some internal means of doing something similar to what is proposed here, so first we should check what Trinidad is doing. Can you check/send a mail with Trinidad in the subject line?
regards, Martin On 12/20/07, Cristi Toth <[EMAIL PROTECTED]> wrote: > What Thomas said about Trinidad and any other component library with their > own state manager is very true. > It would be nice to have the SerializedViewCollection (the view pool from > JspStateManagerImpl) to be delegated to handle the actual storing of the > views. > But that still implies modifying those state managers.... > > On Dec 20, 2007 11:01 AM, Nicu Mercioiu <[EMAIL PROTECTED]> wrote: > > > My solution doesn't work only with commandLinks but works as well with > > outputLink or JavaScript by adding a GET parameter like in the > > following example: > > > > <h:outputLink value="multipleFrames.jsf" target="_blank"> > > <f:param name="target" value="_blank"/> > > </h:outputLink> > > > > It also works for any submitted form with a target attribute, for > > example a form submitted by commandButton. > > > > Regards, > > > > Nicu > > > > On Dec 20, 2007 10: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 > > > > > > > > > > > > -- > Cristi Toth > > ------------- > Codebeat > www.codebeat.ro > -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
