Author: buildbot
Date: Thu Feb 13 22:16:49 2014
New Revision: 897823

Log:
Staging update by buildbot for deltaspike

Modified:
    websites/staging/deltaspike/trunk/content/   (props changed)
    websites/staging/deltaspike/trunk/content/jsf.html

Propchange: websites/staging/deltaspike/trunk/content/
------------------------------------------------------------------------------
--- cms:source-revision (original)
+++ cms:source-revision Thu Feb 13 22:16:49 2014
@@ -1 +1 @@
-1566683
+1568066

Modified: websites/staging/deltaspike/trunk/content/jsf.html
==============================================================================
--- websites/staging/deltaspike/trunk/content/jsf.html (original)
+++ websites/staging/deltaspike/trunk/content/jsf.html Thu Feb 13 22:16:49 2014
@@ -81,7 +81,12 @@
               <div class="toc">
 <ul>
 <li><a href="#multi-window-handling-todo">Multi-Window Handling (TODO)</a><ul>
-<li><a href="#intro">Intro</a></li>
+<li><a href="#intro">Intro</a><ul>
+<li><a href="#historic-considerations">Historic Considerations</a></li>
+<li><a href="#how-jsf-2-changed-the-world">How JSF-2 changed the world</a></li>
+<li><a href="#standard-windowid-handling">Standard windowId Handling</a></li>
+</ul>
+</li>
 <li><a href="#available-modes">Available modes</a><ul>
 <li><a href="#clientwindow">CLIENTWINDOW</a><ul>
 <li><a href="#advantage">Advantage</a></li>
@@ -171,19 +176,33 @@
 <hr />
 <h1 id="multi-window-handling-todo">Multi-Window Handling (TODO)</h1>
 <h2 id="intro">Intro</h2>
+<h3 id="historic-considerations">Historic Considerations</h3>
+<p>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. </p>
+<h3 id="how-jsf-2-changed-the-world">How JSF-2 changed the world</h3>
+<p>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.</p>
+<h3 id="standard-windowid-handling">Standard windowId Handling</h3>
+<p>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 solution.</p>
 <h2 id="available-modes">Available modes</h2>
 <h3 id="clientwindow">CLIENTWINDOW</h3>
 <p>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 <code>dsRid</code>) 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.</p>
+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.
+<br/>
+For POST request detection, the windowId will be added as hidden input to all 
forms.</p>
 <h5 id="advantage">Advantage</h5>
 <ul>
 <li>Covers all edge cases</li>
 </ul>
 <h5 id="disadvantage">Disadvantage</h5>
 <ul>
-<li>Every GET requests streams the the windowhandler.html first -&gt; The
-    application probably feels a litte bit slower</li>
+<li>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.</li>
 </ul>
 <h4 id="change-windowhandlerhtml">Change windowhandler.html</h4>
 <p>To customize the look &amp; feel of the windowhandler.html, you can simply 
provide a own via:</p>
@@ -289,6 +308,11 @@ The best way, to apply it for all views,
 
 
 <h2 id="based-scopes">Based Scopes</h2>
+<ul>
+<li>@WindowScoped</li>
+<li>@ViewAccessScoped</li>
+<li>@GroupedConversationScoped</li>
+</ul>
 <h1 id="type-safe-view-configs">Type-safe View-Configs</h1>
 <h2 id="intro_1">Intro</h2>
 <p>Type-safe view-configs are static configs which can be used in combination 
with every view-technology which is based on Java.


Reply via email to