You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@myfaces.apache.org by bansi <ma...@yahoo.com> on 2008/08/21 20:33:51 UTC
JSF: Multiple browser windows sharing Same session
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.
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? 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.
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
--
View this message in context: http://www.nabble.com/JSF%3A-Multiple-browser-windows-sharing--Same-session-tp19094409p19094409.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: JSF: Multiple browser windows sharing Same session
Posted by John Carlson <ca...@llnl.gov>.
Perhaps you should keep a state machine in the database as to where
the user is in the work flow. If you get an event which isn't
allowed, you know your user did something wrong. You'll have to
track each state machine individually, which is what the
"conversation" or "dialog" scope is all about. So there are other
choices besides request, session and application. To keep track of
each state machine, you'll have to pass a token to the client and
have the client return it. Think of it as an extended session
id. The tools out there are Seam, Spring Web Flow and Orchestra and
maybe others. If you only want one state machine per session, then
you'll have to enforce the state machine on the server side.
One or two people here recommend this tool:
http://tox.sourceforge.net
It's not JSF. Oh well.
John
At 08:29 PM 8/21/2008, John Carlson wrote:
>You would keep state on the client by rewriting your application as
>a java application (using Java Web Start for example). That
>probably is not acceptable to you or your management. Thus you are
>left with session management--returning the right view based on
>where the user is in your web site. That is what tools like
>Orchestra and Spring Web Flow provide.
>
>bansi wrote:
>
>>Hi Zummy,
>>How do i keep the state on client.
>>What are the pros & cons of this approach
>>
>>
>>Zummy wrote:
>> >
>> > Answer: keep the state on the client. Have you considered Spring
>> > Web Flow, or are you stuck on an old version of Spring?
>> >
>> > John
>> >
>> > At 11:33 AM 8/21/2008, you 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.
>> >>
>> >>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? 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.
>> >>
>> >>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
>> >>--
>> >>View this message in context: http:// www.
>> >>nabble.com/JSF%3A-Multiple-browser-windows-sharing--Same-session-
>> tp19094409p19094409.html
>> >>Sent from the MyFaces - Users mailing list archive at Nabble.com.
>> >
>> >
>> >
>>
>>--
>>View this message in context: http:// www.
>>nabble.com/JSF%3A-Multiple-browser-windows-sharing--Same-session-tp19094409p19096746.html
>>Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: JSF: Multiple browser windows sharing Same session
Posted by John Carlson <ca...@llnl.gov>.
You would keep state on the client by rewriting your application as a
java application (using Java Web Start for example). That probably
is not acceptable to you or your management. Thus you are left with
session management--returning the right view based on where the user
is in your web site. That is what tools like Orchestra and Spring
Web Flow provide.
bansi wrote:
>Hi Zummy,
>How do i keep the state on client.
>What are the pros & cons of this approach
>
>
>Zummy wrote:
> >
> > Answer: keep the state on the client. Have you considered Spring
> > Web Flow, or are you stuck on an old version of Spring?
> >
> > John
> >
> > At 11:33 AM 8/21/2008, you 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.
> >>
> >>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? 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.
> >>
> >>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
> >>--
> >>View this message in context: http:// www.
> >>nabble.com/JSF%3A-Multiple-browser-windows-sharing--Same-session-t
> p19094409p19094409.html
> >>Sent from the MyFaces - Users mailing list archive at Nabble.com.
> >
> >
> >
>
>--
>View this message in context: http:// www.
>nabble.com/JSF%3A-Multiple-browser-windows-sharing--Same-session-tp19094409p19096746.html
>Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: JSF: Multiple browser windows sharing Same session
Posted by bansi <ma...@yahoo.com>.
Hi Zummy,
How do i keep the state on client.
What are the pros & cons of this approach
Zummy wrote:
>
> Answer: keep the state on the client. Have you considered Spring
> Web Flow, or are you stuck on an old version of Spring?
>
> John
>
> At 11:33 AM 8/21/2008, you 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.
>>
>>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? 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.
>>
>>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
>>--
>>View this message in context: http:// www.
>>nabble.com/JSF%3A-Multiple-browser-windows-sharing--Same-session-tp19094409p19094409.html
>>Sent from the MyFaces - Users mailing list archive at Nabble.com.
>
>
>
--
View this message in context: http://www.nabble.com/JSF%3A-Multiple-browser-windows-sharing--Same-session-tp19094409p19096746.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: JSF: Multiple browser windows sharing Same session
Posted by John Carlson <ca...@llnl.gov>.
Answer: keep the state on the client. Have you considered Spring
Web Flow, or are you stuck on an old version of Spring?
John
At 11:33 AM 8/21/2008, you 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.
>
>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? 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.
>
>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
>--
>View this message in context: http:// www.
>nabble.com/JSF%3A-Multiple-browser-windows-sharing--Same-session-tp19094409p19094409.html
>Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: JSF: Multiple browser windows sharing Same session
Posted by Scott O'Bryan <da...@gmail.com>.
I did a solution for JDEdwards a while back to handle multiple windows.
You're mostly on base Simon. There are a couple of things that could
really take your flexibility to the next level though (if you have the
stomach for it.. We did and it really paid off).
1. Don't tie the application scopes to a browser. There should be the
concept of a window (which handles the window by name) and then a
concept of the active application within that window. Posts to the
server are made using the window, but then sent, essentially, to the
application.
2. The special handling is confined to session scoped objects only. If
you can ensure that a request gets directed to the right view,
request-scoped attributes are fine. As should application scoped
attributes.
3. Close window detection is extreemly helpful as well. Modern browsers
can know about a closed window 90% of the time. This way you know what
windows SHOULD be active and how many windows are open. This might
allow you to clean up the session early and whatnot.
In the system we had of JDEdwards (admittedly pre-JSF) we maintained a
list of running applications off to the side of each browser window. If
the application was currently displayed in an active and open browser
window, we brought it forward. If it wasn't currently being displayed
in the browser window, it brought it up over the current application
while the other application remained running. Furthermore, extending
this into a portal type environment (where multiple apps can be actively
displayed in the same window) was a snap as well.
Just some things to think about.
Scott
Simon Kitching wrote:
> simon.kitching@chello.at schrieb:
>> Eelco Hillenius schrieb:
>>>
>>>> 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.
>>>>
>>>
>>> Actually, Wicket has an out-of-the-box solution for this. Wicket
>>> works with
>>> 'page maps', which roughly represent the same thing as browser
>>> windows, and
>>> we have some magic going for detecting new browser windows. It's a best
>>> effort that works for most of the cases out there, but while we
>>> never get
>>> complaints about it, there are probably a few corner cases that fall
>>> through.
>>>
>>> For anyone interested, take a look at INewBrowserWindowListener and
>>> WebPage#renderHead for the source code. Not the easiest code to follow
>>> (after all, it's a bit of a nasty problem to solve), but it might
>>> give you
>>> ideas on how to solve it for JSF.
>>>
>>> I saw someone else suggesting that keeping all your state on the client
>>> would solve this. This is true, but it may open up a bunch of security
>>> holes. Certainly when you assumed your state to be safe before. Also,
>>> depending on 'how much' state is concerned, it might mean a
>>> considerable
>>> efficiency hit. The most extreme example I've seen was an ASP.NET
>>> page with
>>> over a megabyte of serialized state. That should be avoidable, but
>>> things
>>> can add up quickly, so you should at least keep an eye on it.
>>>
>>
>> Thanks very much for the info! I will have a look at the Wicket
>> solution..
>
> I have (finally) had a look at the wicket code, and it is indeed
> interesting. It's not a perfect solution, but is useful. Thanks for
> pointing it out, Eelco!
>
> The core insight is that when open-in-new-tab is used, or a bookmark
> is activated, or a url is pasted into a window, the browser always
> creates a new javascript Window object. This object will have fresh
> values for the built-in properties (window.name etc) and will not have
> any custom javascript properties at all.
>
> So *after* a page has been loaded by the new window, javascript in the
> page can check window.name or look for custom javascript properties to
> find out whether the window is a new one. If the page being rendered
> did not expect to be rendered into a new window then it can use
> javascript to set window.location to tell the server about it. In
> particular, it can ask the server to allocate a new "window context"
> and then render a new page (or the same page again).
>
> When server processing of a request has triggered allocation of a new
> "window context", then it should simply render javascript into the
> page head that sets the appropriate window property (window.name or
> custom javascript property); it expects to be rendered into a "new"
> window. When server processing of a request has reused an existing
> "window context" then it should render script that checks for the
> magic state and redirects if the window is new. Typically the url
> redirected to tells the server to allocate a new "window context" then
> re-render the same page. The javascript to achieve this is pretty
> trivial.
>
> There are the following issues:
>
> (1) This approach does require javascript to be activated on the
> browser; when javascript is not activated then the
> new-window-detection simply has no effect.
>
> (2) It only detects the problem *after* a request has been rendered on
> the server and streamed back to the browser. If the request has
> side-effects then the original window is now out-of-sync. However all
> of the use-cases (open-in-new-window, activate-bookmark,
> copy-paste-url) result in GET operations, and according to the
> principles of REST, no GET operation should affect server state.
>
> Note in particular that for JSF server-side-state-saving a new
> view-state will have been pushed into the cache before the problem is
> detected. This state will never be used again (but is "newer" than the
> state for the original window).
>
> (3) The new window may flicker a bit, as it shows the first page then
> immediately redirects. Or does putting the javascript check in the
> page head prevent this? I would guess that the bad page is present in
> the history anyway...
>
> (4) It does require script to be rendered into every page (preferably
> into the head section). In most webapps that's not too hard to
> arrange, but a lib like Orchestra cannot automatically set that up.
>
>
> Of course there is also the issue that simply *detecting* new windows
> is not enough; there needs to be some kind of per-window-storage too.
> Wicket takes care of that, and so can Orchestra. But Orchestra does
> not (yet) have an easy way to render the appropriate javascript checks.
>
> Regards,
> Simon
>
Re: JSF: Multiple browser windows sharing Same session
Posted by Simon Kitching <sk...@apache.org>.
simon.kitching@chello.at schrieb:
> Eelco Hillenius schrieb:
>>
>>> 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.
>>>
>>
>> Actually, Wicket has an out-of-the-box solution for this. Wicket
>> works with
>> 'page maps', which roughly represent the same thing as browser
>> windows, and
>> we have some magic going for detecting new browser windows. It's a best
>> effort that works for most of the cases out there, but while we never
>> get
>> complaints about it, there are probably a few corner cases that fall
>> through.
>>
>> For anyone interested, take a look at INewBrowserWindowListener and
>> WebPage#renderHead for the source code. Not the easiest code to follow
>> (after all, it's a bit of a nasty problem to solve), but it might
>> give you
>> ideas on how to solve it for JSF.
>>
>> I saw someone else suggesting that keeping all your state on the client
>> would solve this. This is true, but it may open up a bunch of security
>> holes. Certainly when you assumed your state to be safe before. Also,
>> depending on 'how much' state is concerned, it might mean a considerable
>> efficiency hit. The most extreme example I've seen was an ASP.NET
>> page with
>> over a megabyte of serialized state. That should be avoidable, but
>> things
>> can add up quickly, so you should at least keep an eye on it.
>>
>
> Thanks very much for the info! I will have a look at the Wicket
> solution..
I have (finally) had a look at the wicket code, and it is indeed
interesting. It's not a perfect solution, but is useful. Thanks for
pointing it out, Eelco!
The core insight is that when open-in-new-tab is used, or a bookmark is
activated, or a url is pasted into a window, the browser always creates
a new javascript Window object. This object will have fresh values for
the built-in properties (window.name etc) and will not have any custom
javascript properties at all.
So *after* a page has been loaded by the new window, javascript in the
page can check window.name or look for custom javascript properties to
find out whether the window is a new one. If the page being rendered did
not expect to be rendered into a new window then it can use javascript
to set window.location to tell the server about it. In particular, it
can ask the server to allocate a new "window context" and then render a
new page (or the same page again).
When server processing of a request has triggered allocation of a new
"window context", then it should simply render javascript into the page
head that sets the appropriate window property (window.name or custom
javascript property); it expects to be rendered into a "new" window.
When server processing of a request has reused an existing "window
context" then it should render script that checks for the magic state
and redirects if the window is new. Typically the url redirected to
tells the server to allocate a new "window context" then re-render the
same page. The javascript to achieve this is pretty trivial.
There are the following issues:
(1) This approach does require javascript to be activated on the
browser; when javascript is not activated then the new-window-detection
simply has no effect.
(2) It only detects the problem *after* a request has been rendered on
the server and streamed back to the browser. If the request has
side-effects then the original window is now out-of-sync. However all of
the use-cases (open-in-new-window, activate-bookmark, copy-paste-url)
result in GET operations, and according to the principles of REST, no
GET operation should affect server state.
Note in particular that for JSF server-side-state-saving a new
view-state will have been pushed into the cache before the problem is
detected. This state will never be used again (but is "newer" than the
state for the original window).
(3) The new window may flicker a bit, as it shows the first page then
immediately redirects. Or does putting the javascript check in the page
head prevent this? I would guess that the bad page is present in the
history anyway...
(4) It does require script to be rendered into every page (preferably
into the head section). In most webapps that's not too hard to arrange,
but a lib like Orchestra cannot automatically set that up.
Of course there is also the issue that simply *detecting* new windows is
not enough; there needs to be some kind of per-window-storage too.
Wicket takes care of that, and so can Orchestra. But Orchestra does not
(yet) have an easy way to render the appropriate javascript checks.
Regards,
Simon
Re: JSF: Multiple browser windows sharing Same session
Posted by "simon.kitching@chello.at" <si...@chello.at>.
Eelco Hillenius schrieb:
>
>> 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.
>>
>
> Actually, Wicket has an out-of-the-box solution for this. Wicket works with
> 'page maps', which roughly represent the same thing as browser windows, and
> we have some magic going for detecting new browser windows. It's a best
> effort that works for most of the cases out there, but while we never get
> complaints about it, there are probably a few corner cases that fall
> through.
>
> For anyone interested, take a look at INewBrowserWindowListener and
> WebPage#renderHead for the source code. Not the easiest code to follow
> (after all, it's a bit of a nasty problem to solve), but it might give you
> ideas on how to solve it for JSF.
>
> I saw someone else suggesting that keeping all your state on the client
> would solve this. This is true, but it may open up a bunch of security
> holes. Certainly when you assumed your state to be safe before. Also,
> depending on 'how much' state is concerned, it might mean a considerable
> efficiency hit. The most extreme example I've seen was an ASP.NET page with
> over a megabyte of serialized state. That should be avoidable, but things
> can add up quickly, so you should at least keep an eye on it.
>
Thanks very much for the info! I will have a look at the Wicket solution..
Keeping state on the client is not actually a problem for JSF. By
default the serialized state is encrypted before being passed to the
client. So while users can fake inputs for fields (which they were
allowed to type into anyway) they cannot easily fake the state.
You're absolutely right about the performance issues. Having a filter
that warns when pages get too big is a useful tool if going down this route.
Regards, Simon
Re: JSF: Multiple browser windows sharing Same session
Posted by Eelco Hillenius <ee...@gmail.com>.
> 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.
Actually, Wicket has an out-of-the-box solution for this. Wicket works with
'page maps', which roughly represent the same thing as browser windows, and
we have some magic going for detecting new browser windows. It's a best
effort that works for most of the cases out there, but while we never get
complaints about it, there are probably a few corner cases that fall
through.
For anyone interested, take a look at INewBrowserWindowListener and
WebPage#renderHead for the source code. Not the easiest code to follow
(after all, it's a bit of a nasty problem to solve), but it might give you
ideas on how to solve it for JSF.
I saw someone else suggesting that keeping all your state on the client
would solve this. This is true, but it may open up a bunch of security
holes. Certainly when you assumed your state to be safe before. Also,
depending on 'how much' state is concerned, it might mean a considerable
efficiency hit. The most extreme example I've seen was an ASP.NET page with
over a megabyte of serialized state. That should be avoidable, but things
can add up quickly, so you should at least keep an eye on it.
Eelco
--
View this message in context: http://www.nabble.com/JSF%3A-Multiple-browser-windows-sharing--Same-session-tp19094409p19098795.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: JSF: Multiple browser windows sharing Same session
Posted by simon <si...@chello.at>.
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
Re: JSF: Multiple browser windows sharing Same session
Posted by Jan Baumann <ja...@andrena.de>.
You could use a session wide page counter that you could store for
example in a hidden field. Each request increments the counter by one.
While this does not tell you exactly which window the request is from,
it would allow you to make sure the request is part of the current flow
of pages and does not originate from an older page which may have used
older / different data. While not very elegant it is a rather simple
approach that does not need request scope, other frameworks or a big
overhead and it does prevent the multi window errors I could think of.
Cheers
Jan
bansi schrieb:
> 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.
>
> 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? 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.
>
> 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
Re: JSF: Multiple browser windows sharing Same session
Posted by "Kito D. Mann" <km...@virtua.com>.
Bansi,
You really should try orchestra. It has very little conceptual
overhead for what you want to accomplish, and will definitely save you
time.
Sent from my iPhone
On Aug 21, 2008, at 1:33 PM, bansi <ma...@yahoo.com> 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.
>
> 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?
> 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.
>
> 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
> --
> View this message in context: http://www.nabble.com/JSF%3A-Multiple-browser-windows-sharing--Same-session-tp19094409p19094409.html
> Sent from the MyFaces - Users mailing list archive at Nabble.com.
Re: JSF: Multiple browser windows sharing Same session
Posted by bansi <ma...@yahoo.com>.
What happens if
KEEP_STATE_IN_SESSION set the property to false in web.xml file.
I guess then JSF will not keep the states of the application in the session.
Will this leads to keeping the state in the client.
What are the Pros/Cons of this approach ???
Please note we are using JSF session scope backing beans. i.e. the component
tree (state) is in session
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.
>
> 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? 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.
>
> 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
>
--
View this message in context: http://www.nabble.com/JSF%3A-Multiple-browser-windows-sharing--Same-session-tp19094409p19094933.html
Sent from the MyFaces - Users mailing list archive at Nabble.com.