[ http://jira.jboss.com/jira/browse/JBSEAM-1712?page=comments#action_12394021 ] Andy Gibson commented on JBSEAM-1712: ------------------------------------- Not sure it needs to recognize that it is a nested PC, just a vanilla old PC would be good enough. However, after looking at nested conversations, and the thinking behind them, I'm not sure we need this JIRA given that nested conversations weren't meant for editing details, but to provide multiple paths for editing data in the original conversation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-1712?page=com.atlassian.jira.pl... ] Jacob Orshalick updated JBSEAM-1712: ------------------------------------ Fix Version/s: The future Yes, I'll start digging on this one and we can get it scheduled once I have an idea of the changes involved. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-1712?page=com.atlassian.jira.pl... ] deanhiller commented on JBSEAM-1712: ------------------------------------ hmmm, I didn't know an issue for this existed. Actually, I know there would be issues with nested conversations done this way, but it might be easier than what we are going through on our project right now. We literally have had to start copying the db model so if the action was cancelled, we could just throw it away. We have a very long non-linear wizard :(. How do I say this better? You know the booking app where it is kind of like a tree where when you are finally done, there was a single line and path to the end. With out app, we are a tree where the user constantly is saving parts of his changes and coming back around in the tree. It is very non-linear and very painful to write in seam(kind of regretting not using GWT for this particular problem actually). Of course, struts or JSF would have been even more painful. We have save points on most pages but not all and we force saves before certain parts(ie. we would force saves before nested conversations if nested conversations would work like the above!!!!). This would make life easier in our application. Here is a basic scenario in our world and users want changes saved at lots of steps so we flush alot.... 1. user edits script 2. user edits a question 3. user adds a variable definition to question and clicks ok going back to question 4. user adds a gotorule on the question(here is a save point and we flush..but would love a nested conversation after the flush) 5. at this point, we literally copy the ejb model so cancel will work and we can just throw away the copy. On save, we copy the changes back to the ejb model...yuck yuck yuck(ie. we can't use the typical throw away the conversation as we are way to deep in the conversation now). If on number 5, we had this new persistence context in the nested conversation, I could hopefully throw away all of #5's changes!!! We have made it so all of #5's changes would not cause integrity problems. Anyways, hard to explain all the nightmares of this app. I wish I could relay going through the experiences we have gone through. They have not been too fun. Seam is great when you just want one linear path through editing but when you want something this complex, seam is still the closest answer but in this case GWT would have been cake whereas seam made it tougher :(. though doing the graphics in GWT is a pain to make it look real nice :(. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

[ https://jira.jboss.org/jira/browse/JBSEAM-1712?page=com.atlassian.jira.pl... ] Maximiliano Carrizo commented on JBSEAM-1712: --------------------------------------------- I'm sorry, Dean, but the idea of using persistence context is to avoid flushing until use case is finished. I don't want to flush parent conversation, because I have to remove later this records if I don't finish my use case. The requirement is to create a nested persistence context WITHOUT flushing anything.... but, of course, this is just my opinion. Best regards -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://jira.jboss.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira