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
>
>
