Well, as i see, there is no simple solution to this problem :-( The possible one to reconstruct any links in the rendered page is a very rough one, i think. To implement a page persistency and associate the data object in dependence on a cookie value seems to be smarter - if it works.
But i think, the simpliest and smartest way would be, if i would hustle our customer to drop this requirement ;-) Just kidding ;-) I'll have a look on both of your suggestions, and would appreciate other ones. Thank you very much so far. best, Rene "Tapestry users" <tapestry-user@jakarta.apache.org> schrieb am 04.04.05 21:16:33: > > > 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] > ______________________________________________________________ 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]
