deltaspike-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject svn commit: r1568066 - /deltaspike/site/trunk/content/jsf.mdtext
Date Thu, 13 Feb 2014 22:15:27 GMT
Author: tandraschko
Date: Thu Feb 13 22:15:27 2014
New Revision: 1568066

window handling...


Modified: deltaspike/site/trunk/content/jsf.mdtext
--- deltaspike/site/trunk/content/jsf.mdtext (original)
+++ deltaspike/site/trunk/content/jsf.mdtext Thu Feb 13 22:15:27 2014
@@ -23,6 +23,22 @@ Notice:    Licensed to the Apache Softwa
 ## Intro
+### Historic Considerations
+Until the end of the 1990s web browsers are usually single threaded and only had one window.
But in the last years browsers supporting multiple windows or even tab became the standard.
Since those days lots of efforts went into uniquely identifying a single browser window on
the server side. Sadly browser windows still lack of a native windowId, thus maintaining web
application data in @SessionScoped backing beans is still used in most of the cases. 
+###How JSF-2 changed the world
+The MyFaces Orchestra community did a good summary about the various ways to handle multiple
window support in JSF Applications. Those findings are still valid and up to date, but the
environmental conditions have changed slightly since then.
+<br />
+It is easy to pass a windowId around with a POST request, but it gets tricky with GET requests.
Due to the new JSF-2 ability to use bookmarkable URLs and deep links, a typical JSF-2 application
contains much more GET links than we used to see in JSF-1, thus we have far more href links
to cope with.
+### Standard windowId Handling
+With a classical approach we would not be able to simply add a windowId parameter to such
links because if the user would open the link in a new browser window or tab, we would carry
the windowId - and thus the window scope - over to the new browser tab/window. The classic
solution was to omit the windowId for all GET links, but by doing this we would now loose
the window scope far too often with JSF-2!
+<br />
+Marios summary also contains a method to prevent this problem by storing a value directly
in the browser window via JavaScript. Usually this is rendered and executed in the same page
as the user form. See the "Post-render window detection" paragraph for a more detailed description.
+The major downside of this solution is that we might already pollute 'foreign' beans (and
destroy their information) while rendering the page, which means this is not feasible as general
 ## Available modes
@@ -30,6 +46,8 @@ Notice:    Licensed to the Apache Softwa
 Each GET request results in an intermediate small html page which checks if the browser tab
fits the requested windowId. <br/>
 When the windowId is valid, a unique token (called `dsRid`) will be generated for the current
request and added to the URL. <br/>
 In addition a cookie with with the dsRid/windowId will be added. On the server side, the
verified windowId will be takes from the cookie.
+For POST request detection, the windowId will be added as hidden input to all forms.
 ##### Advantage
@@ -38,8 +56,9 @@ In addition a cookie with with the dsRid
 ##### Disadvantage
-  - Every GET requests streams the the windowhandler.html first -> The
-    application probably feels a litte bit slower
+- Having the windowhandler.html site rendered between requests sometimes leads to some 'flickering'
if the destination page takes some time to load. The browser first renders our windowhandler
and only after that the original page will get loaded. <br/>
+This effect may be minimized by branding the windowhandler.html page and providing an own
one with a bgcolor which matches your application.<br/>
+For html-5 aware browsers we also got rid of this flickering by storing away a 'screenshot'
of the first page in onclick() and immediately restore this 'screenshot' on the intermediate
windowhandler.html page. Technically we do this by storing away the <body> and css information
into the html5 localStorage and restore them on the intermediate page. We also introduced
a WindowConfig which is able to parse a request and decide upon the UserAgent or any other
information if a client will get an intermediate page or if he gets the result page directly.
 #### Change windowhandler.html
@@ -157,6 +176,10 @@ Don't forget to set the ClientWindowRend
 ## Based Scopes
+  - @WindowScoped
+  - @ViewAccessScoped
+  - @GroupedConversationScoped
 # Type-safe View-Configs
 ## Intro

View raw message