It's not exactly the same but goes in the same direction. Currently we have 4 'operation modes' for each request (see ClientWindowConfig.
* NONE: no @WindowScoped will be available for this request * LAZY: the windowId will be verified and ensured on the client side via a JavaScript comparison of the windowId and window.name and if it doesn't fit then we force a page refresh with the correct windowId: CON: the first page hit will still have the old windowId and might touch beans from this other window. * CLIENTWINDOW: each GET request first gets an intermediate page (windowhandler.html) which checks if the windowName and windowId fit. If not -> new windowId will get requested. If they fit, we reload the page with the verified windowId. This 2nd request finally hits the xhtml page. The intermediate windowhandler page takes around 1ms to get served and is blazingly fast on the client. To prevent flickering if the target page takes some time to render we kind of take a DOM screenshot from the original page and display it on the intermediate page. * CUSTOM: A user might implement his own ClientWindow. Not sure though how we will integrate this. Currently doesn't work :) The user can choose them via his own ClientWindowConfig (or @Specializes DefaultClientWindowConfig) for each request. E.g. a Request from an internal address in a company (in our case the university) gets the ClientWndow (intermediate html page which ensures the windowId is correct) and external addresses get rendered directly. Bots and other crawlers should also get the direct page for example. Now for the 'exclude region' sometimes you don't like to decorate target links with the windowId, nor do you like to store the DOM tree in the localstorage. E.g. if you show customer generated context which is not secured or if you have links to external pages. This is more or less a security mechanism. LieGrue, strub >________________________________ > From: Christian Kaltepoth <christ...@kaltepoth.de> >To: deltaspike-dev@incubator.apache.org >Cc: Mark Struberg <strub...@yahoo.de> >Sent: Tuesday, 23 April 2013, 23:15 >Subject: Re: windowId postback detection > > >@Mark >With your 'exclude-area' idea you are referring to something like >Orchestra's <o:separateConversationContext>, right? I think this could be a >really interesting feature for some usecases and we >should definitively support it. > >Regarding the auto detection for links that have to be decorated: I'm not >really sure if there is a need to explicitly configure a set of domains for >this. I guess the decorating is somehow similar to what >HttpServletResponse.encodeURL() does and would even be implemented by >wrapping it (or the corresponding stuff in ExternalContext), correct? So >why don't we simply decorate all links that go though encodeURL unless we >are in an exclude area case? > >Christian > > > > >2013/4/23 Jason Porter <lightguard...@gmail.com> > >> Interesting idea. What does the rest of the community think? >> >> >> On Tue, Apr 23, 2013 at 11:01 AM, Mark Struberg <strub...@yahoo.de> wrote: >> >> > yes, we will certainly need to do lots of testing with this new approach. >> > But it seems much more in sync with the JSF-2.2 idea which requires to >> > detect the proper windowId even before the restore-view phase. In the old >> > CODI implementation we parsed it from a custom Component which we added >> to >> > the view tree ourselfs. maybe we can do both. >> > >> > There was also an idea about having an 'exclude-area'. Means a tag which >> > will exclude the containing GET links from using the browser tab >> detection. >> > We might also think about a mechanism to detect the links which need to >> > get decorated. Something like >> > >> > <ds:windowId domain="this, someurl.com, otherurl.org"/> >> > For other links we will not add the windowId nor store away the dom tree >> > for our 'snapshot view' on the intermediate page. >> > >> > LieGrue, >> > strub >> > >> > >> > >> > >> > ----- Original Message ----- >> > > From: Jason Porter <lightguard...@gmail.com> >> > > To: "deltaspike-dev@incubator.apache.org" < >> > deltaspike-dev@incubator.apache.org> >> > > Cc: >> > > Sent: Tuesday, 23 April 2013, 18:22 >> > > Subject: Re: windowId postback detection >> > > >> > > I'm good either way, but the custom component idea seems to be >> consensus, >> > > also if the user doesn't want it they can always leave out the new >> > > component. >> > > >> > > >> > > On Mon, Apr 22, 2013 at 12:38 AM, Thomas Andraschko < >> > > andraschko.tho...@gmail.com> wrote: >> > > >> > >> +1 for the custom component >> > >> >> > >> >> > >> 2013/4/22 Christian Kaltepoth <christ...@kaltepoth.de> >> > >> >> > >> > I like the idea of a custom component because it makes it more >> > > explicit >> > >> > what the component is used for and perhaps would even provide more >> > >> control >> > >> > over what is happening. >> > >> > >> > >> > So +1 for a custom component >> > >> > >> > >> > >> > >> > 2013/4/21 Mark Struberg <strub...@yahoo.de> >> > >> > >> > >> > > Gerhard brought up another alternative: simply provide a >> > > component >> > >> which >> > >> > > doesn't render any html but adds the windowhandler.js and >> > > stores the >> > >> > > component in the ViewRoot. >> > >> > > >> > >> > > LieGrue, >> > >> > > strub >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > ----- Original Message ----- >> > >> > > > From: Romain Manni-Bucau <rmannibu...@gmail.com> >> > >> > > > To: Mark Struberg <strub...@yahoo.de>; >> > >> > > deltaspike-dev@incubator.apache.org >> > >> > > > Cc: >> > >> > > > Sent: Sunday, 21 April 2013, 20:56 >> > >> > > > Subject: Re: windowId postback detection >> > >> > > > >> > >> > > > 1 sounds easier to track too >> > >> > > > Le 21 avr. 2013 18:09, "Mark Struberg" >> > > <strub...@yahoo.de> a >> > >> > > > écrit : >> > >> > > > >> > >> > > >> Hi! >> > >> > > >> >> > >> > > >> There are technically 2 options for extracting the >> > > windowId on >> > >> POSTs: >> > >> > > >> >> > >> > > >> 1.) setting a hidden UIOutput component in the ViewRoot >> > >> > > >> >> > >> > > >> >> > >> > > >> 2.) provide a custom renderkit/ResponseStateManager >> > >> > > >> >> > >> > > >> I think 1.) is much easier. Any input? >> > >> > > >> >> > >> > > >> LIeGrue, >> > >> > > >> strub >> > >> > > >> >> > >> > > >> >> > >> > > > >> > >> > > >> > >> > >> > >> > >> > >> > >> > >> > -- >> > >> > Christian Kaltepoth >> > >> > Blog: http://blog.kaltepoth.de/ >> > >> > Twitter: http://twitter.com/chkal >> > >> > GitHub: https://github.com/chkal >> > >> > >> > >> >> > > >> > > >> > > >> > > -- >> > > Jason Porter >> > > http://en.gravatar.com/lightguardjp >> > > >> > >> >> >> >> -- >> Jason Porter >> http://en.gravatar.com/lightguardjp >> > > > >-- >Christian Kaltepoth >Blog: http://blog.kaltepoth.de/ >Twitter: http://twitter.com/chkal >GitHub: https://github.com/chkal > >
