[jbossseam-issues] [JBoss JIRA] Commented: (JBSEAM-1712) Allow options for SMPC per Nested Conversation

[deanhiller (JIRA)]

    [ https://jira.jboss.org/jira/browse/JBSEAM-1712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12490394#action_12490394 ] 

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 :(.



> Allow options for SMPC per Nested Conversation
> ----------------------------------------------
>
>                 Key: JBSEAM-1712
>                 URL: https://jira.jboss.org/jira/browse/JBSEAM-1712
>             Project: Seam
>          Issue Type: Feature Request
>          Components: Core
>    Affects Versions: 2.0.0.BETA1
>         Environment: Windows XP, Seam 2.0 Beta, JBoss 4.2
>            Reporter: Andy Gibson
>            Assignee: Jacob Orshalick
>             Fix For: The future
>
>
> I'd like to request the option to specify that a nested conversation gets it's own entity manager instance as opposed to sharing it with it's parent conversation and other nested conversations. 
> The problem with nested conversations is that you can't actually use them to edit multiple entities since when you flush the PC, you flush it for all conversations. This makes nested conversations only really useful for browsing data, and creating new top level conversation to edit items to isolate the flushes.
> The only alternative is to use a non-Seam managed PC, and make use of the "PC per stateful bean" rule to map a single PC to a single backing bean, but you lose the benefits of a seam managed PC.
> What might be nice is something like :
> @Begin(nested=true, newPC=true)
> and
> <begin-conversation nested="true" newPC="true"/>
> which would indicate that this new nested conversation gets it's own entity manager instance. The attribute would be ignored if this wasn't a nested conversation, and obviously, by default, the attribute is set to false, and a shared PC would be used in the nested conversation in such cases.
> I'm already using one PC per conversation by using top level conversations to edit items, I'd just like to use one PC per nested conversation (where applicable) to get the benefits of nested conversations.
> There are a couple of posts in the forums where I've touched on some of my problems with this issue : 
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=111681
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=111384
> http://www.jboss.com/index.html?module=bb&op=viewtopic&t=113362

-- 
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