<snip>
I don't think we're talking about the same thing here.
I have two instances of the same page up.
Neither is stale.
Each is showing a different database object. One shows a Dog. The
other shows a Cat. The Dog was loaded first, then the Cat. If the user tries
to modify the Dog, its updates will get posted onto the Cat page because the
Cat is in persistent storage.
Neither the dog, nor the cat, is stale. Both are still backed by
perfectly viable page objects. Both are still backed by a perfectly viable
session. Neither will throw the "stale page" flag if saved.
The problem area lies in that Tapestry's persistence layer
overwrites the persistent properties of the "Dog" page with those of the
"Cat" page when it is loaded up within the same session.
As I've mentioned before, I'm more than capable of working around
this behavior by the simple expedient of rolling my own persistence method.
From where I'm sitting though the issue is this:
The fact that I can't successfully persist two copies of the same
page within the same session basically makes the Tapestry Persistence layer
useless to me. I can't count on the users not doing "open in new window" or
"Open in new Tab".
There's lots of doc out there though that references the tapestry
persistence layer and lots of people who sure seem to be using it. So my
question is:
Is there a way to make the tapestry persistence layer work in the
situation I originally described? If not, why hasn't this been an issue for
other users? Is it a case that prior to firefox "open in new window" was
never used so this situation never cropped up? Or is there some sort of a
known workaround?
--- Pat
>
> This has always been the case, there is nothing preventing the browser
> from opening several views to a server using the same session. Otherwise
> how would for example pop-up windows work?
> You have to take this into consideration no matter what web-framework
> you use. If you think about it this is comes from the fact that HTTP is
> a stateless protocol. Someone once described it as a fax-protocol. The
> webserver sends a fax with the page - say an order form. The browser
> faxes the users order (POST) to the server.
> The server really has no clue which order-form the user looked at when
> posting the data to the server. The page might not even have anything to
> do with the page flow the programmer assumed, there is alweays the back
> button, bookmarks, cached information, several windows and so on.
> The best you can do is to try to detect that the information the browser
> POSTs to the server is old and the user needs to see a fresh order form.
> This is what Tapestry uses the rewind and stale link messages to tell
> the user.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
