myfaces-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Marinschek" <martin.marinsc...@gmail.com>
Subject Re: Server state saving and multiple frames
Date Thu, 20 Dec 2007 14:39:18 GMT
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 <cristi.toth@gmail.com> 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 <iri.mercioiu@gmail.com> 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 <simon.kitching@chello.at> 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 <martin.marinschek@gmail.com> 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 <simon.kitching@chello.at> 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

Mime
View raw message