Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "MyFaces Development" <dev@myfaces.apache.org>
Message-ID: <11185139.184381290122833881.JavaMail.jira@thor>
Date: Thu, 18 Nov 2010 18:27:13 -0500 (EST)
From: "Mark Struberg (JIRA)" <dev@myfaces.apache.org>
To: dev@myfaces.apache.org
Subject: [jira] Commented: (EXTCDI-79) introduce client side windowhandler
In-Reply-To: <653205.182831290116955412.JavaMail.jira@thor>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/EXTCDI-79?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12933606#action_12933606 ] 

Mark Struberg commented on EXTCDI-79:
-------------------------------------

initial funkctionality committed.

TODO: 
a.) make the resource path for the windowhandler.html configurable to allow different backgroundcolors and other stuff
b.) think about caching strategies for the windowhandler.html for high-load scenarios.

> introduce client side windowhandler
> -----------------------------------
>
>                 Key: EXTCDI-79
>                 URL: https://issues.apache.org/jira/browse/EXTCDI-79
>             Project: MyFaces CODI
>          Issue Type: New Feature
>          Components: JEE-JSF20-Module
>    Affects Versions: 0.9.0
>            Reporter: Mark Struberg
>
> A typical JSF-2 application contains much more GET links than we used to see in JSF-1. Thus we have far more href link to cope with.
> 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.
> There is a method to prevent this problem by storing a value directly in the browser window via JavaScript. Usually this is done in the same page and gets executed in the onLoadEvent like described in Marios old Orchestra summary. See "Post render window detection" in http://myfaces.apache.org/orchestra/myfaces-orchestra-core/multiwindow.html
> The major downside of this solution is that we might already pollute 'foreign' beans (and destroy their information) while rendering the page.
> Our new approach now works around this issue by introducing a small static new html window which gets served via a small servlet (Jsf2WindowHandlerServlet). It gets an 'url' and after detecting a new window it will drop the windowId parameter via JavaScript on the client and forwards to the destination page. For creating the destination link I'll override the encodeBookmarkableURL in an ExternalContextWrapper.
> Instead of the original URL: http://localhost:8080/course/courseDetails.xhtml?windowId=1c9f&courseNr=101348&semester=2010W
> we will create a :  http://localhost:8080/course/windowhandler?url=%2Fcourse%2FcourseDetails.xhtml%3FwindowId%3D1c9f%26courseNr%3D101348%26semester%3D2010W
> The windowhandler servlet serves a simple html which is cachable (TBD), thus it doesn't lead to duplicated server roundtrips (beside the first time).

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.