On Thu, 2008-08-21 at 11:33 -0700, bansi wrote: > We are using JSF 1.2, MyFaces 1.2.2, Spring, Hibernate > One of the biggest problems of JSF appears to be that it requires that most > backing beans be placed into session scope.
Well, I don't think this is particularly a JSF problem. You can write a JSF application using request-scoped beans. One possible exception is tables containing input components; that seems to me to be impossible to handle with request scope. Of course using only request scope is painful and can be a performance problem (repeated database reads). But AFAIK the issues are no different when using Struts or Rails or whatever. > > Is there anything you can do on the technical side to work around these > problems that stem from storing e.g. a ListDataModel in the session? Just read the list again on each request? Yes, it's not great for performance. But that does provide stateless behaviour. > How do > you handle master detail views and paging in tables without conflicts > between multiple browser windows sharing the same session? > > How do you sell the limitation to one browser window per user to your > customers? > > Its too late in the project to use MyFaces Orchestra . So please any other > pointers/suggestions will be highly recommended. One of Orchestra's benefits is that it can be introduced into an existing application without causing complications. It can be applied to just a few pages where problems exist without needing to be spread throughout the application. But one thing Orchestra still struggles to solve is multiple concurrent browser windows. It does provide the ability to separate data per-window. However actually figuring out which requests come from which window is very difficult; orchestra provides a way to do this which works as long as the user cooperates a little, but cannot solve it 100% (see below). I've spent quite a lot of time trying to solve the issue of multiple-windows-with-server-side-state. Eventually I came to the conclusion that it would need a change to the http specification itself (the browser must provide a per-window id as an http header). Again, I don't see this as being particularly a JSF problem. I can't imagine that struts or wicket or rails would be able to deal with this problem any easier. Http simply does not provide a way to tell requests from different windows apart, except by the data embedded in the url query params or the POSTed data content. But webapps cannot be written with 100% POST requests, and query params are too easy for browsers to "clone" when opening new windows. So the only completely bullet-proof solution is to not bother trying to tell them apart on the server, and instead have 100% of the application state encoded in the browser form or query-params. Actually, even that doesn't work completely as there will typically be "state" stored in back-end databases which multiple windows can still have trouble with. Unfortunately working in this "stateless server" approach is difficult to code, and typically a major performance issue, no matter what webapp framework you use. > > Here is what we are thinking in terms of Solution > Solution Proposal: > 1)Is it possible to disable File-> New Window in case of IE and File-> New > Tab in case of Firefox > 2)Is it possible to detect the session already exists when users open > another browser instance . And then give Alert message to the user and > automatically close the other browser instance No to both of these, unfortunately. At least as far as I know. Firefox main menus are not an issue, as file->new tab opens a blank page. But IE's behaviour of cloning the existing url is a problem. What is possible is to disable the right-click+open-in-new-window option for links. That can be done by rendering all links as having a url of "javascript:void(0)" and then using an onclick to actually fetch the new page. Detecting that the session already exists is not possible. The browser has absolutely no way of telling which window a request came from - unless there is a "window id" encoded in the url. What Orchestra does is encode a window-id into every url as it is rendered into the page (it wraps the ServletResponse object and overrides the encodeURL method). The webapp author can explicitly mark certain links as popping up a new window, and these do NOT have the windowId. So the user can click on these to get a second window that works correctly (that window accesses a different orchestra conversation context, which is like having a different http session). Together with disabling the right-click menu option for links this works reasonably well. But even then, "file|new window" in IE, or simply copying and pasting the url into a new window will stuff things up. User objects can be stored into attributes of the JSF view (either on a specific component, or more commonly on the view-root). Together with client-side-state-saving this means that it effectively provides a "view" scope without server-side state which can be very useful. Of course the user objects must be serializable (so no hibernate entities) and should not be too large. The Tomahawk t:saveState tag is a convenient way to use this feature. Strangely, the performance issue is less of a problem in very small-scale systems (not much state) and large-scale ones (eg google gmail where clustering is widely employed). But for most of us, that middle ground is exactly where server-side state is useful. Regards, Simon
