If the browser really is a "new instance", ie one that does not share
the same http session, then the two browser windows will not interact in
any way.
That's not what you describe below, so clearly in your case, the second
browser window you are opening *is* attached to the same "browser
instance", and does share the same http session.
You must also have "server side state saving" enabled, ie the JSF tree
is being stored in the same session (this is the default). With this
configuration, as far as the server is concerned, the two windows cannot
be told apart. All data is in the session and the two windows use the
same session, so there isn't much JSF can do.
You can turn on "client side state saving", which embeds the JSF tree
into a hidden field in the html form rather than saving it into the http
session. This does allow multiple windows within the same browser
instance to be independent. There are issues with this, though:
(a) it reduces memory usage on the server, but greatly increases the
amount of data sent between server and client. If your network is slow,
client-side state saving is not good.
(b) if you have 2 windows using the same http session, then you had
better not use *any* objects stored into the http session scope, as
otherwise the two windows will interact for obvious reasons.
Note that if you start MS-IE twice, then the two windows are separate
instances, and have separate http sessions; user will have to re-login
with second window but the two windows are then quite independent. If
you start Firefox twice then both windows actually belong to the same
instance and share the same http session. I personally wish Firefox
didn't do that, but AFAIK there is no easy way to force a new instance.
Regards,
Simon
On Fri, 2007-08-31 at 14:16 +0400, Evgeniy Karimov wrote:
> As it seems, the problem is described as a feature in comments in tomahawk
> source code:
> ---
> * Note that the saved object can be "chained" from view to view
> * in order to extend its lifetime from a single view to a sequence
> * of views if desired. A UISaveState component with an EL expression
> * such as "#{someBean}" will save the object state after render, and
> * restore it on postback. If navigation occurs to some other view
> * and that view has a UISaveState component with the same EL expression
> * then the object will simply be saved into the new view, thus extending
> * its lifetime.
> Seems when I reload same page in another instance of browser, JSP thinks that
> it's another view with same binding expression available, and restores same
> object, which I want to cancel. Is it possible in any way?
>
> -----Original Message-----
> From: Евгений Каримов <[EMAIL PROTECTED]>
> To: [email protected]
> Date: Fri, 31 Aug 2007 12:50:52 +0400
> Subject: Tomahawk Savestate strange behaviour
>
> >
> > Hi, I have some question about Tomahawk Savestate component:
> >
> > I create a simple for with 3 input boxes, and 1 submit button. I bind
> > their values to some backBean, which is marked as "request" scope.
> > And I have
> > <t:saveState value="#{backBean}"></t:saveState>
> > tag.
> >
> > Before I added saveState tag, when I reopen a page in same browser - the
> > values of bean (and corresponding component values) were new (empty), after
> > I added saveState tag - backBean started to behave as Session bean, not as
> > "view" scope bean... I mean it shouldn't persist through different queries,
> > right?
> > Thanks in advance.
> >
