The obvious window tracking implementation is one based on URL rewriting. This will ensure that a window will be identified by a unique URL.
Having two windows A and be B their corresponding URLs will look like http://host:port/context/file.jsf?jsfwid=A and http://host:port/context/file.jsf?jsfwid=B. Even though both windows show the same view they can have different states (captured by the window scope beans).
The advantages of using URL rewriting are:
- The window can still be tracked after a window reload, the browser will send a GET request using the URL that contains the window identifier.
- The window is still tracked when a navigation is triggered, the URLs rendered by the application will all contain the window identifier.
- The URL rewriting can be implemented by using the API that is available in JSF (encodeActionURL(url)).
- ICEfaces can use the URL rewriting based window tracking that is already provided by JSF and implement only the window scope management (which is missing from JSF).
- The bridge will need minor changes to send the window identifier into a format recognised by JSF.
The disadvantages of using URL rewriting are:
- Components that render URLs to other views need to be updated to encode the window identifier.
- Confusions can occur when the URL of the page is copied and used in another window, thus having two windows tracked by the same identifier. Certain strategies can be added to eliminate this duplication.
- More complex URLs, deployments that use reverse proxies or servlet filters will have to account for the new URL pattern.