Say I have a page to edit an entity, and that includes a table component. When the page is rendered, various bits of state about components of the page are stored in the session, especially for the table component, since it stores current page and various other things in the session.
Now, my users want to bring up the EditObject page for an object with id 1, then bring up the same page for an object with id 2 in a different window. Now they make some edits to object 1 based on information visible in the entity 2 page. When they click submit, however, they will get a stale link exception (if they are lucky. If they are unlucky, they could wind up making their changes to entity 2 instead of entity 1). Is there any way to prevent this. Multiple similar windows is fundamental to the way my users want to work (of course, they didn't tell me this until the app was all the way through testing and had been released), and it appears as though Tapestry's persistence mechanism makes it utterly impossible to provide, since I would need some kind of mechanism that would ensure that all state about a page were persisted to the client, rather than to the session, and I don't have any way to do that for components that I don't control. I could rewrite every component I use which has persistent properties, I guess, but that's a huge amount of work and code duplication. I don't suppose there is some kind of undocumented method of associating a unique id with a page instance so that all session persistent data associated with the page were stored under a page:uniqueId combination, preventing conflicts with other instances of the same page. Of course, then I need some way to clean the session of state for a single instance, as well as for all instances of a given page, and that method clearly doesn't exist in the API, so I am concerned that this isn't possible at all. I'm in tap 4.0 for now, but likely negotiating an upgrade to tap 4.1 in the near future. While I'm at it, I haven't seen anyone complain about the inherent security vulnerabilities that come along with client side persistence, as implemented . Storing the true or false values for every conditional in a form as an (unsigned/unencrypted) hidden field is just asking for a user to change an F to a T in order to gain access to something they shouldn't. It seems strange to me that the default would be to store the state in the form, and you have to explicitly request tapestry not to do so. I'd love an override which would cause tapestry to assume conditionals and iterations are volatile unless I explicitly request otherwise. To my mind, defaults should always be the MORE secure option, and then on those conditions and iterations which aren't at risk, set volatile to false. But really, I want all client side persistence to include a hash of the values (or encrypt them) so that we can automatically detect malicious modifications on the part of a user. --sam --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
