I guess you could say, "An application where those
footing the bill (Client) demand it". But, it's not
application specific, and it's not multiple sessions
we're talking about here, it's multiple browsers on
the same session. Multiple sessions are a non-issue.
Regardless of what your application is, one of the
following should be true:
1) You do nothing about multiple browsers on the
same session, and
a) You use no session data
b) You take your chances that session data may
become corrupt
2) You prevent multiple browsers on the same session
through
a) JavaScript (Risky, since it could be turned
off)
b) Synchronized Tokens?
3) You do something to segregate the session data
between browsers.
1b is not acceptable to most Clients since their data
is at risk, and when it is acceptable, you still take
the chance that you may have corrupted data to fix. 2
is acceptable for most Clients, data integrity tends
to be a higher priority than keeping the end user
happy. When, however, the Client insists on data
integrity and optimal ease of use, you're left to
implement 1a or 3.
[OT] If your real question was what "Under what
circumstances would a user want more than one browser
accessing a given application, regardless of whether
or not they have the same session�, the answers are
many. How about a warehouse application where the
Customer Service Representatives need to see Orders,
Inventory, and Customer data, at the same time? It�s
not always acceptable to anticipate what combinations
of data they need to see at the same time, and can it
into a screen. Nor is it acceptable to tell them they
have to keep navigating from one to another
constantly. The answer is, they want multiple
browsers viewing whatever datum is of interest to them
at the moment.
m
--- Doug <[EMAIL PROTECTED]> wrote:
> Michael Ruppin wrote:
> > I'm reconsidering my approach to this problem, in
> > favor of something more elegant/more compatible
> with
> > out-of-the-box Struts. Anyone tackled this yet?
> >
> > For those not aware, MS IE allows users to launch
> a
> > browser against the same session via
> File/New/Window
> > (Ctrl-N). The issue is, if you have need to keep
> data
> > in the session (which I do), a submission from one
> > browser could grab and/or overwrite session data
> meant
> > for the other browser. This can lead to data
> > integrity problems and other weirdness. Telling
> my
> > user community not to use MS IE or it's Ctrl-N
> feature
> > is not an option.
> >
> > My current approach is to put a hidden random
> "key"
> > into the HTML, and name the session attribute with
> > that. When one of the two browsers submits a
> request
> > (Assuming, at this point, they've opened another)
> the
> > session data is pulled by key, assigned a new key,
> a
> > new copy is placed in the session named with the
> new
> > key, and the new key is rendered in the HTML
> > response. The old session data may or may not be
> > removed, depending on whether or not it is
> acceptable
> > for the browser with the old key to [gracefully]
> fail,
> > how we choose to expire session data, and whether
> or
> > not a means of dealing with stale data is
> supported by
> > the model.
> >
> > This works fine, but in doing so I've had to write
> my
> > own methods for populating collections of forms
> which
> > would have otherwise been taken care of for me by
> > specifying session scope in struts-config. Am I
> > missing a better way?
> >
> > m
>
> Out of curiosity, what kind of application do you
> have where you really
> *need* to support someone having multiple different
> sessions active at
> the same time? I'm not necessarily saying that you
> don't need this -
> I'm just wondering. You may be bending over
> backwards to solve a
> problem that real users (as opposed to testers)
> won't have.
>
>
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
