users want to load same page with different entities in parallel. How?
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]
Re: users want to load same page with different entities in parallel. How?
ok, some investigation into the version of contrib:Table that comes with tacos shows that you can specify that a table stores its persistent state to the client on a page or app basis, so it would appear that that is solved for the table component. Are there other components in the core libraries (tapestry, contrib, tacos) which have persistent properties stored in the session? If not, then I can just modify my forms to store the entity id in the form (currently, I've got them in a session state object) and force the correct entity to be reloaded when the page is submitted and everything else should come together with minimal fuss, I think. --sam On 11/8/06, Sam Gendler [EMAIL PROTECTED] wrote: 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]
Re: users want to load same page with different entities in parallel. How?
Storing data to the client is always an option but for larger amounts of data this becomes a problem due to large amount of data that needs to be encoded in the urls of every link or in hidden fields of a form. I think what you are looking for is a way to scope the session data so that you can have separate threads referencing distinct data. If I recall correctly, this type of scope is not directly supported by tapestry natively as it is in other frameworks (like Jboss Seam for example). I find the Conversation strategy very useful and I implement it pretty easily yourself. What I do is I generate a numeric ConversationId at the beginning of a new wizard. I store this Id in a property with @Persist(client). I then have a HashMap that is stored to the session and use this id as the key to store whatever data I need (for example storing a state object). You can then automate the retriaval of this state object from the session on each request by attaching a listener before the page begins to render. This has proven to work good at least for me. I'm sure you could also try to implement a new persistent scope in hivemind to somewhat automate this better and make it more clean. But this seemed easy enough to do that I didn't feel it necessary to go that far. I think it'd be really good if in the future such functionality was integrated into the framework. The idea is to have some way to easily delineate when the scope of a conversation starts/stops some method for expiring dead conversations and of course, allowing multiple independent concurrent conversations at the same time. Although I have never actually used it, I think Seam is based around the idea of contextual conversations and might serve as a good starting point for seeing this idea in action. On 11/8/06, Sam Gendler [EMAIL PROTECTED] wrote: ok, some investigation into the version of contrib:Table that comes with tacos shows that you can specify that a table stores its persistent state to the client on a page or app basis, so it would appear that that is solved for the table component. Are there other components in the core libraries (tapestry, contrib, tacos) which have persistent properties stored in the session? If not, then I can just modify my forms to store the entity id in the form (currently, I've got them in a session state object) and force the correct entity to be reloaded when the page is submitted and everything else should come together with minimal fuss, I think. --sam On 11/8/06, Sam Gendler [EMAIL PROTECTED] wrote: 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
Re: users want to load same page with different entities in parallel. How?
Yeah, it is easy to do it with session state that I control. My concern is purely with components that have their own persistent fields, so I can't make them 'conversation-aware' without some amount of hacking. This bothers my sense of elegance. Sure, it is doable, especially since every tap components I have ever seen is open source, but I sure don't want to have to do it. Being able to associate all session state with a conversation in the framework itself would be fantastic, especially if the conversation id were part of the request cycle, so it could be discovered automagically whenever anything is persisted to the session. The real trick then, of course, is to make it simple to determine when a new conversation should be started vs using a previously existing one. At least in my app, however, it would be acceptable to force users to click an 'edit in new window' link in order to start a new conversation. I'll have to look into doing a persistence strategy like that. --sam On 11/8/06, Daniel Tabuenca [EMAIL PROTECTED] wrote: Storing data to the client is always an option but for larger amounts of data this becomes a problem due to large amount of data that needs to be encoded in the urls of every link or in hidden fields of a form. I think what you are looking for is a way to scope the session data so that you can have separate threads referencing distinct data. If I recall correctly, this type of scope is not directly supported by tapestry natively as it is in other frameworks (like Jboss Seam for example). I find the Conversation strategy very useful and I implement it pretty easily yourself. What I do is I generate a numeric ConversationId at the beginning of a new wizard. I store this Id in a property with @Persist(client). I then have a HashMap that is stored to the session and use this id as the key to store whatever data I need (for example storing a state object). You can then automate the retriaval of this state object from the session on each request by attaching a listener before the page begins to render. This has proven to work good at least for me. I'm sure you could also try to implement a new persistent scope in hivemind to somewhat automate this better and make it more clean. But this seemed easy enough to do that I didn't feel it necessary to go that far. I think it'd be really good if in the future such functionality was integrated into the framework. The idea is to have some way to easily delineate when the scope of a conversation starts/stops some method for expiring dead conversations and of course, allowing multiple independent concurrent conversations at the same time. Although I have never actually used it, I think Seam is based around the idea of contextual conversations and might serve as a good starting point for seeing this idea in action. On 11/8/06, Sam Gendler [EMAIL PROTECTED] wrote: ok, some investigation into the version of contrib:Table that comes with tacos shows that you can specify that a table stores its persistent state to the client on a page or app basis, so it would appear that that is solved for the table component. Are there other components in the core libraries (tapestry, contrib, tacos) which have persistent properties stored in the session? If not, then I can just modify my forms to store the entity id in the form (currently, I've got them in a session state object) and force the correct entity to be reloaded when the page is submitted and everything else should come together with minimal fuss, I think. --sam On 11/8/06, Sam Gendler [EMAIL PROTECTED] wrote: 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
