This problem reminds me of an article, "The Law of Leaky
Abstractions":
http://www.joelonsoftware.com/articles/LeakyAbstractions.html
The obvious answer is
1) Don't keep any state server-side (ie. Visit/HttpSession), possibly
this could be overriding tapestry persistence mechanism to use
cookies.
The problem is that your HttpSession is going to be associated with
the
all browser instances (at least across browser type, say IE), so you
can't transparently handle state server-side. You can possibly get
close
if you figure out how to associate a specific different Visit with
each
specific browser window (possibly using techniques as below), but what
about things like "login"?
2) If you don't want the same login information across these windows,
you are OK (assuming you can pull off the visit/browser window trick,
remember you can't store the window instance descriptor itself in the
session). I think generally, you would store Visits within the
HttpSession, keyed by some cookied value that describes the window
that
you are communicating with (with one possibly being a "default").
3) If you want some common information across these windows, then you
have a custom solution, and probably want to support another
persistence
"style" in a generic way (ie. page, _window_, session), again using a
solution like as in 2). Maybe you clone the window information when
they
have a new window, it depends I suppose. I'm not sure how you support
the new persistence type either, but that's what you would have.
Joel
-----Original Message-----
From: Anatoli Krassavine [mailto:[EMAIL PROTECTED]
Sent: Monday, April 04, 2005 9:58 AM
To: Tapestry users
Subject: Re: How to handle multiple instances of a page with different
data in the same session, at the same time ?
Hello Erik,
Correct me if I am wrong, but it seems to me that
this is not enough for what Rene needs (and what I
needed).
I am very happy to be proven wrong on this subject -
will save me lots of hassle, so let me describe a
scenario.
Basically, imagine that I have a page with good deep
component hierarchy. Say 100 links encoded at
different levels of hierarchy including generic
components.
I want to have several such pages opened in
different browser windows by the same user (i.e.
within same user session as far as Tapestry is
concerned), each with its own separate workflow.
Simple example (yes, I know it is very artificial,
so please do not flak me on this):
1) client runs 3 searches with different queries
2) each search opens a new window with separate
hitlist
3) in each window we have different pagination, sort
options, et cetera, et cetera
4) client wants to be able to switch between windows
seemlessly maintaining the context within each window
5) specifically generic links encoded within generic
components must maintain the page context
Cheers,
Toly
--- Erik Hatcher <[EMAIL PROTECTED]> wrote:
I don't know how this would be accomplished in the
cleanest way, but in
Tapestry 3.1 (errr, "Picaso") the property
persistence is pluggable
with a builtin capability of persist="session". I
suppose clever links
and services could key off of properties marked as
persist="page" such
that links were encoded with those properties
automatically (but you
wouldn't want all links encoded this way probably)
and that they'd be
extracted and re-set on each request by the service.
What would it take to do this type of thing?
Erik
On Apr 4, 2005, at 6:46 AM, Anatoli Krassavine
wrote:
3) There are several approaches to this, but the
only
generic one is to encode "window" information in
links. Other approaches include creative handling
of
cookies and javascript, but they are tricky and
provide poor cross-platform compatibility.
4) The whole point of Tapestry is a complete
abstraction of HTML representation from actual
HTTP
workflows, hence link encoding should be done
transparently and cover ALL links on all
participating
pages.
5) The best way to achieve this is to provide a
wrapper service. This service will wrap standard
services (Action, Direct, etc).
When generating a representation of HTML link:
a) extract context information fro mthe current
page
instance
b) encode relevant information into the link by
appending an extra parameter (at the end)
c) then pass control to wrapped service to
generate
link in a "normal" way
When processing the request:
a) extract information from the link
b) store it in requestCycle as an attribute
c) pass control to wrapped service.
d) page instance could check the attribute in
requestCycle and act accordingly
I think it cover it all and works quite well.
Cheers,
Toly
[EMAIL PROTECTED]
Software Architect
--- [EMAIL PROTECTED] wrote:
Hi @all,
in my current project, i have to ensure, that a
user
can work with
multiple instances of the same page, but every
page
instance has different data.
Means, that he can open multiple windows with the
same page. With a
plain page, this should be no problem, but in
this
case, the page
contains a TabPanel, which, as we all know,
forces a
page reload in
case of changing the current tab page. In other
cases, it is necessary
to reload the page with a "location.href" refresh
in
javascript, without
a form submit.
The problem is:
if the user opens the page to display data object
A,
after that opens
another instance of the same page with data
object
B, goes back to A
and does something with this instance (i.e.
forcing
a page reload or
changing the tab page), the data of object B is
displayed in page A, because it was the
last data object bound to this tapestry page.
Hope, you can understand, what i mean.
How can i handle this ?
best,
Rene
______________________________________________________________
Verschicken Sie romantische, coole und witzige
Bilder per SMS!
Jetzt bei WEB.DE FreeMail:
http://f.web.de/?mc=021193
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
Send instant messages to your online friends
http://uk.messenger.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail:
[EMAIL PROTECTED]
For additional commands, e-mail:
[EMAIL PROTECTED]
Send instant messages to your online friends
http://uk.messenger.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
