Re: statefulness, and multiple tabs
dont think a conversation scope will be of much help to you. wicket does support it via jboss' cdi implementation, but i think you are better off stashing all the changes into some dto and applying them when the save button is pressed. -igor On Mon, May 3, 2010 at 12:13 PM, Ray Weidner ray.weidner.develo...@gmail.com wrote: I have a question about how to approach a certain kind of problem. Let me first explain what I'm doing, and then what the problem is with that. For the web app I'm creating, a user can, using a web form, edit data which is backed by a model that fetches the persistent object being modified. When the OK button is clicked, the changes are committed, and then show up in the database. So far, so good. While editing a given record called Issue, the user may choose to edit other records that it references (AffectedParty, in this case). To do this, we switch to the new page without performing any commit. When the referenced record is updated, the user returns to the original Issue record. So far, nothing has been committed. All changes will committed when editing is complete for the Issue record. The problem occurs when users open multiple tabs to multiple Issues. In this case, my persistence framework (Hibernate) is using one session for all updates, so a commit to one will affect all the others. This can cause all kinds of complex problems when the user is editing multiple unrelated records at the same time. I would like this application to be able to support working on multiple records at once. One place this can be fixed is in the persistence layer, by associating unrelated records with separate Sessions. However, this can get complicated, fast. Another thing that I might try is to detach the record from Hibernate at the end of each page being rendered, and reattach it at the time of update. Right now, this seems like the most reasonable solution. Is there a standard Wicket solution for this problem? A friend of mine who uses Seam suggested that I check out whether or not Wicket supports conversations, a concept with which I'm only partly familiar (they're like transactions, but can comprise multiple individual transactions...right?). So far, it looks to me like Wicket doesn't directly support this concept, and I'm not even sure how it would help me, anyway. Any suggestions? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: statefulness, and multiple tabs
I think you may be able to separate those things into transactions using spring annotation based transactions? So then you can handle your transactions being created / flushed by a method scope - so the data will be flushed to DB when the method invokation is finished. You can read more at: http://static.springsource.org/spring/docs/2.0.4/reference/transaction.html Žilvinas Vilutis Mobile: (+370) 652 38353 E-mail: cika...@gmail.com On Mon, May 3, 2010 at 12:13 PM, Ray Weidner ray.weidner.develo...@gmail.com wrote: I have a question about how to approach a certain kind of problem. Let me first explain what I'm doing, and then what the problem is with that. For the web app I'm creating, a user can, using a web form, edit data which is backed by a model that fetches the persistent object being modified. When the OK button is clicked, the changes are committed, and then show up in the database. So far, so good. While editing a given record called Issue, the user may choose to edit other records that it references (AffectedParty, in this case). To do this, we switch to the new page without performing any commit. When the referenced record is updated, the user returns to the original Issue record. So far, nothing has been committed. All changes will committed when editing is complete for the Issue record. The problem occurs when users open multiple tabs to multiple Issues. In this case, my persistence framework (Hibernate) is using one session for all updates, so a commit to one will affect all the others. This can cause all kinds of complex problems when the user is editing multiple unrelated records at the same time. I would like this application to be able to support working on multiple records at once. One place this can be fixed is in the persistence layer, by associating unrelated records with separate Sessions. However, this can get complicated, fast. Another thing that I might try is to detach the record from Hibernate at the end of each page being rendered, and reattach it at the time of update. Right now, this seems like the most reasonable solution. Is there a standard Wicket solution for this problem? A friend of mine who uses Seam suggested that I check out whether or not Wicket supports conversations, a concept with which I'm only partly familiar (they're like transactions, but can comprise multiple individual transactions...right?). So far, it looks to me like Wicket doesn't directly support this concept, and I'm not even sure how it would help me, anyway. Any suggestions? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
statefulness, and multiple tabs
I have a question about how to approach a certain kind of problem. Let me first explain what I'm doing, and then what the problem is with that. For the web app I'm creating, a user can, using a web form, edit data which is backed by a model that fetches the persistent object being modified. When the OK button is clicked, the changes are committed, and then show up in the database. So far, so good. While editing a given record called Issue, the user may choose to edit other records that it references (AffectedParty, in this case). To do this, we switch to the new page without performing any commit. When the referenced record is updated, the user returns to the original Issue record. So far, nothing has been committed. All changes will committed when editing is complete for the Issue record. The problem occurs when users open multiple tabs to multiple Issues. In this case, my persistence framework (Hibernate) is using one session for all updates, so a commit to one will affect all the others. This can cause all kinds of complex problems when the user is editing multiple unrelated records at the same time. I would like this application to be able to support working on multiple records at once. One place this can be fixed is in the persistence layer, by associating unrelated records with separate Sessions. However, this can get complicated, fast. Another thing that I might try is to detach the record from Hibernate at the end of each page being rendered, and reattach it at the time of update. Right now, this seems like the most reasonable solution. Is there a standard Wicket solution for this problem? A friend of mine who uses Seam suggested that I check out whether or not Wicket supports conversations, a concept with which I'm only partly familiar (they're like transactions, but can comprise multiple individual transactions...right?). So far, it looks to me like Wicket doesn't directly support this concept, and I'm not even sure how it would help me, anyway. Any suggestions?
