[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
Hi Pete, thanks for your post and please excuse my late response, too. I hardly followed this forum in October and therefore didn't notice earlier that you posted a response in this thread. [EMAIL PROTECTED] wrote : | Wolfgang Schwendt wrote : And the following approach is not viable either: We cannot simply access a component from the parent conversation and call a property Setter of this component with the ending result of the nested conversation supplied as argument for this Setter. | | This is what you are supposed to be able to do. | | | Wolfgang Schwendt wrote : The reason is that when a component from the parent conversation is called while the nested conversation is still in progress, the ManagedEntityIdentityInterceptor saves wrappers for the called component in the scope of the nested conversation (!) and not the scope of the parent conversation. | | I'm 90% sure this is a bug. Do you have a JIRA issue open for it? Can you point me at it if you do? I need to review it carefully with Norman. | ok, if one is really supposed to call a component of the parent conversation in order to transfer the result of the nested conversation, the behavior looks indeed like a bug.By the way, in the meantime another thread regarding the problem was opened by Denis Karpov in late October: http://www.jboss.com/index.html?module=bbop=viewtopict=121852 Therefore, as requested and in face of the second thread, I opened a JIRA issue at the weekend (you probably have noticed it already). http://jira.jboss.com/jira/browse/JBSEAM-2209 [EMAIL PROTECTED] wrote : | anonymous wrote : I'm puzzled by the fact that Seam offers nothing yet in this regard. A feature like that would be highly useful when modeling complex flows and composing them of one or more subflows. I hope that an output-mapper gets added to Seam, in order to avoid having to resort to ugly hacks such as writing from the nested conversation to the parent conversation scope. | | | | Even if you were able to write attributes back to the parent conversation do you still think this would be useful? from a technical point of view, it would not be necessary.It would already be a big improvement if it was possible to transfer state to the parent conversation by way of an explicit method call (invocation of a component of the parent conversation). Nevetheless, from a software engineering perspective, an output mapper feature could still be very useful. But I'd need to write a more detailed explanation about that, with this post I just want to mention the JIRA case. And such an output mapper feature would have to be carefully designed. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4101731#4101731 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4101731 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
Sorry about the delay getting to this thread. wschwendt wrote : One problem is that unfortunately Gavin King appears to be no longer present on this forum (yes, I understand that he's probably awfully busy and cannot answer mundane support questions here). If you can persuade it us it's worth us looking at we can distill it down for him and see what he says (yes, its worth looking at IMO :) ). Gavin is busy with Web Beans atm. anonymous wrote : And the following approach is not viable either: We cannot simply access a component from the parent conversation and call a property Setter of this component with the ending result of the nested conversation supplied as argument for this Setter. This is what you are supposed to be able to do. anonymous wrote : The reason is that when a component from the parent conversation is called while the nested conversation is still in progress, the ManagedEntityIdentityInterceptor saves wrappers for the called component in the scope of the nested conversation (!) and not the scope of the parent conversation. I'm 90% sure this is a bug. Do you have a JIRA issue open for it? Can you point me at it if you do? I need to review it carefully with Norman. anonymous wrote : I'm puzzled by the fact that Seam offers nothing yet in this regard. A feature like that would be highly useful when modeling complex flows and composing them of one or more subflows. I hope that an output-mapper gets added to Seam, in order to avoid having to resort to ugly hacks such as writing from the nested conversation to the parent conversation scope. | Even if you were able to write attributes back to the parent conversation do you still think this would be useful? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4095020#4095020 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4095020 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
http://jira.jboss.com/jira/browse/JBSEAM-2094 View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4094792#4094792 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4094792 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
Very good point Wolfgang. I also questioned the forum on this and posted a solution to the issue in the following post: http://www.jboss.com/index.html?module=bbop=viewtopicp=4078360#4078360 This is how I am destroying the conversation stack. As per the semantics, destroying the root, destroys the entire stack. Hope that helps. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4086857#4086857 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4086857 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
Thanks, Jacob. Great solution. I'd like to see that included in Seam. And btw, we need the endRoot attribute for the end-conversation element, too. Otherwise we cannot really end the entire conversation stack when a nested conversation throws an exception. | // pages.xml | | exception class=javax.persistence.OptimisticLockException | end-conversation endRoot=true/ // end all conversations up to top-level long-running root conversation (inclusive) | redirect view-id=/error.xhtml | messageAnother user changed the same data, please try again/message | /redirect | /exception | cf. http://www.jboss.com/index.html?module=bbop=viewtopict=112414postdays=0postorder=ascstart=10 View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4086863#4086863 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4086863 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
I raised a feature request in JIRA for this: http://jira.jboss.com/jira/browse/JBSEAM-1943 Maybe it could get included in the next release. I would also like to see a feature for more out-of-the-box continuation support with nested conversations. While the solution I've been using works, it would be nice if you could specify @Begin(nested=true, snapshot=true) to get this behavior auto-magically. Turn it on only when needed to avoid needless memory usage on the server. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4086900#4086900 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4086900 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
Hi Jacob, So you're not using a SMPC. I guess I tend to assume everybody uses them. :-) My bad. So I understand more, but I'm still missing a few pieces. jacob.orshalick wrote : ...Seam has taken a snapshot of my Person entity in the outer conversation on nesting (which didn't have the new addresses). The original Person instance will be reverted back to should the user back up to the original edit Person screen and submit. Seam retrieves the outer conversation by id on submit and restores the state of my Person object at the time of the snapshot which doesn't include the new addresses. | It seems like you're embellishing Seam's behavior a little bit. It's my understanding that when you begin a nested conversation, Seam doesn't take a snapshot, it just creates a new empty container, and prevents you from storing new objects in the parent container. While in the nested conversation, new objects are stored in this new container, and lookups look there before looking in the parent container; there's no automatic cloning going on. And if a user backbuttons out of a nested conversation, then there's no restoring going on, either; the nested container is simply not there, so new objects get stored in the parent container and lookups look there first. So, to get the behavior you're talking about, I think you'd need to manually clone the person object when starting a nested conversation. The original state Person would stay in the parent conversation, and the new cloned Person, which might be edited, goes in the nested conversation. I'm guessing you must be doing this cloning manually somehow to get the behavior you describe, but you speak as if it's automatic. Could you explain a little more or show some code? Thanks! View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4085857#4085857 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4085857 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
jacob.orshalick wrote : | | 1. Does the snapshot of the Conversation context include a snapshot of the *managed entity*? | 2. If I make changes to the Person in the nested conversation, since this is a *managed entity* does it make any difference in the semantics of the outer vs. nested conversation? | 3. Will I still be able to revert back to the outer conversation snapshot of my Person object as I can with a detached entity? | I think I need to better understand how your detached-entity system works in order to intelligently answer these, but I'm pretty sure you'll find that seam-managed persistence contexts and nested conversations don't behave how you'd like them to (ie, like continuation servers). Here are some posts that relate: http://www.jboss.com/index.html?module=bbop=viewtopict=111384 http://www.jboss.org/index.html?module=bbop=viewtopict=113362 View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4085869#4085869 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4085869 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
Thanks for the excellent information and the informative links Matt! anonymous wrote : It seems like you're embellishing Seam's behavior a little bit. It's my understanding that when you begin a nested conversation, Seam doesn't take a snapshot, it just creates a new empty container, and prevents you from storing new objects in the parent container | | So, to get the behavior you're talking about, I think you'd need to manually clone the person object when starting a nested conversation. The original state Person would stay in the parent conversation, and the new cloned Person, which might be edited, goes in the nested conversation. You are absolutely correct Matt! I suppose I am embellishing Seam's behavior ;) I am cloning the Person object when starting a nested conversation which would obviously be problematic when using an SMPC since the instance would no longer be managed on cloning. The reason the approach works is performing the merge at the end. The detached instance is merged back with the attached managed instance. Thus, whichever instance it finds first during the lookup (the clone in the nested conversation or the original in the outer conversation) is the instance that is merged. Thanks for increasing my understanding here on use of SMPCs with your information and the provided links. The approach I've used works well for my client (who have many of these mother-child scenarios and do not require an SMPC) but it is important to note that this is not viable for managed entities. One question. If I cloned my Person in the nested conversation and then merged the clone to retrieve the attached instance, I'm assuming I would now have the same reference in both my outer and inner conversation. Is this assumption correct? Thanks again. By the way, on an unrelated note, how are you guys crediting quotes (e.g. jacob orshalick wrote). I want to make sure I'm giving credit where credit is due :) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4086097#4086097 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4086097 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
matt.drees wrote : Hi Jacob, | | So you're not using a SMPC. I guess I tend to assume everybody uses them. :-) My bad. | | So I understand more, but I'm still missing a few pieces. | As for Jacob's approach, I think I roughly understand what he wants to achieve with his use of nested conversations, but so far I cannot completely follow either because some details of his approach are still unknown to us. matt.drees wrote : | jacob.orshalick wrote : ...Seam has taken a snapshot of my Person entity in the outer conversation on nesting (which didn't have the new addresses). The original Person instance will be reverted back to should the user back up to the original edit Person screen and submit. Seam retrieves the outer conversation by id on submit and restores the state of my Person object at the time of the snapshot which doesn't include the new addresses. | | | | It seems like you're embellishing Seam's behavior a little bit. It's my understanding that when you begin a nested conversation, Seam doesn't take a snapshot, it just creates a new empty container, and prevents you from storing new objects in the parent container. While in the nested conversation, new objects are stored in this new container, and lookups look there before looking in the parent container; there's no automatic cloning going on. And if a user backbuttons out of a nested conversation, then there's no restoring going on, either; the nested container is simply not there, so new objects get stored in the parent container and lookups look there first. | | Exactly, I already thought the same yesterday evening. Jacob has repeatedly mentioned that Seam saves snapshots, but I think that is not really the case. Seam manages contexts which are conceptually map-like data structures that associate context variable names (Strings) with object values. As regards contexts and nested conversations, when a new nested conversation is begun, Seam does in fact NOT clone the objects to which context variables from the parent conversation are bound. When a component class is annotated with @PerNestedConversation,however, any component instance of the same name that might exists in the parent conversation is invisible to its child conversations. This may lead to instantiation of a fresh component instance in the scope of a nested conversation when a @PerNestedConversationcomponent is being looked up. Do you make use of this @PerNestedConversationcomponent feature, Jacob? Alternatively, regarding Jacob's mentions of saved snapshots, I was wondering whether perhaps he interprets the side-effects of the ManagedEntityIndentityInterceptor as saving of snapshots. As described in my first post in this thread (#1), when a conversation-scoped component of the parent conversation is called from a nested conversation, the ManagedEntityIndentityInterceptor saves its wrappers for Entity fields or Entity collection fields in the scope of the nested conversation and not the parent conversation. It follows that once the nested conversation context is destroyed and the parent conversation resumes, these saved wrappers are gone, too (if I'm not mistaken).This may appear to be a reversion to a previous snapshot, but it is a reversion only as far as Entity fields or Entity collection fields are concerned. All other fields no wrappers are saved for by the ManagedEntityIndentityInterceptor are not reverted to old values. I'm not sure however whether Jacob's snapshot behavior is caused by the ManagedEntityIndentityInterceptor. If a Seam component is an Entity, no interceptor is added by Seam, thus no ManagedEntityIndentityInterceptor either. matt.drees wrote : | I'm guessing you must be doing this cloning manually somehow to get the behavior you describe, but you speak as if it's automatic. Could you explain a little more or show some code? | we need to know exactly how Jacob's does the management of Entity instances. How are they accessed, are context variables bound to them, and if so, with what scope? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4086108#4086108 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4086108 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
our posts have just overlapped, Jacob. Wasn't aware of your latest follow-up when I clicked the submit button. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4086113#4086113 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4086113 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
and it should always read ManagedEntityIdentityInterceptor, not ManagedEntityIndentityInterceptor (was using copy paste to save some typing and always copied the mistake name with an additional 'n') View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4086116#4086116 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4086116 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
Not a problem Wolfgang, I hope that my post cleared up a lot of your questions. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4086114#4086114 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4086114 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
baz wrote : Very interesting thread. | i like to give a new usecase (or workflow) | We have a search screen, where the user can search for an object(e.g. an experiment) | When navigation to the show/edit screen ocurs a conversation is started and the object(the experiment) is shown. | | Now the user can work with the object(the experiment) | | What comes in now is a subworkflow. This workflow uses a nested conversation and could be started on any page. When this subworkflow ends, the nested conversation ends and redirection to the starting page occurs. | | (...) | | My question is how this kind of workflows can be correctly implemented with seam and conversations? For now, it seems to me that it is nessacary to deliver results from the nested conversation to the outer conversation. | This exactly is the motive why I opened this tread: to request a better (or more elegant) way to transfer state (an ending result) back to the parent conversation when the nested conversation ends. From a modeling perspective, it makes a lot of sense to model a use case (or an activity or workflow) as a composition of sub use cases (or sub-activities). For example, in UML use case diagrams you could define include- or extend- relationships between use cases. In activity diagrams it is possible to model the invocation of sub activities etc. When using Seam for the implementation, these models eventually would have to be mapped to Seam-based code.Clearly, Seam's nested conversation feature is somewhat limited as long as it is akward to transfer state back to the parent conversation (eg. if artificial POJO classes just for this state transfer have to be written). View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4086135#4086135 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4086135 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
jacob.orshalick wrote : | | One question. If I cloned my Person in the nested conversation and then merged the clone to retrieve the attached instance, I'm assuming I would now have the same reference in both my outer and inner conversation. Is this assumption correct? Thanks again. | That's my understanding, yes. I haven't thought enough about it, but maybe you could get continuation-like behavior with SMPCs through careful use of merging. In particular, I wonder if you could create a new persistence context in the nested conversation, merge everything down to it from the parent context, do your editing, and then when you're done, either merge everything back, or flush the child persistence context and refresh the appropriate entities in the parent context. jacob.orshalick wrote : | By the way, on an unrelated note, how are you guys crediting quotes (e.g. jacob orshalick wrote). I want to make sure I'm giving credit where credit is due :) Click on the quote button to the far right of someone's name, and it'll show you the additional syntax you need. Took me a while to catch on, too. :-) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4086156#4086156 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4086156 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
wschwendt wrote : This exactly is the motive why I opened this tread: to request a better (or more elegant) way to transfer state (an ending result) back to the parent conversation when the nested conversation ends. I absolutely agree with you guys that this is a must if you could simply carry the required state changes (and maintain the snapshot of the original conversation for back-button purposes) the problem would be resolved. The issue is if you directly write into the parent conversation, the back-button is always going to cause problems in master-details scenarios unless a snapshot exists. e.g. if Person has addresses added and this is updated to the parent conversation, backing up to the page that does not show the addresses will still persist the addresses on submit as they are a part of that conversation. Spring Web Flow provides a very elegant solution to this through its continuation approach but warn of the potential for high-memory usage. This could be limited if you could specify ONLY the objects that need a snapshot (which is essentially what I've been doing by cloning). matt.drees wrote : I wonder if you could create a new persistence context in the nested conversation, merge everything down to it from the parent context, do your editing, and then when you're done, either merge everything back, or flush the child persistence context and refresh the appropriate entities in the parent context. This is definitely, interesting, will have to look into it. It would be nice if the @PerNestedConversation (which was mentioned before) or some other annotation indicated this type of snapshot behavior. Currently, it looks like it simply means the object is not visible to the nested conversation and is recreated if needed (the documentation also says don't use it). This would be an easy way to specify only which objects you wanted a snapshot of to limit memory usage in a continuation approach. Any other thoughts? ... By the way, thanks for the tip on the quotes Matt :) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4086175#4086175 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4086175 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
wschwendt, I completely understand your problem, but it seems that most of the posts I see about nested conversations are somewhat puzzling to me so I would like to hear some opinions on their usage. I have been using nested conversations in situations where I require a continuation server implementation. After a lot of thought, it seemed that this was the most logical usage of nested conversations given their state snapshot behavior. I have successfully implemented some very complex page flows with master-details editing relationships and all issues with the back button have been alleviated. The user is free to navigate as they please! The main issue that comes in with conversations is the master-details editing where the master controls the persistence of the data. For example, a Person and their Addresses: 1. Select Person for editing which displays a Person edit screen 2. Select Add Addresses which forwards to a secondary screen 3. Addresses are added and the screen is submitted which updates the in-memory Person 4. The Person edit screen is redisplayed with the Addresses added 5. The user then uses the back button to return to the original Person edit screen and submits which persists Person with new addresses If a single long-running conversation was used, you end up submitting addresses that were not intended by the user (at least not what they saw on the browser-cached edit screen) since the Person was updated in the conversation context. If the conversation is nested for the Address details screen, the addition of addresses does not affect the outer conversation. In other words, we have a snapshot of state prior to adding the Addresses. We do NOT end this conversation when the Addresses are submitted. Instead we continue the nested conversation on the new Person edit screen. Now, if the user was to back up to the original Person edit screen, the snapshot of conversation state is restored (the outer conversation) unaffected by the user's actions. If the user then submits, the state is persisted consistent with what the user sees. By updating the outer (parent) conversation backing up to the original Person edit screen has the same effect as using a single long-running conversation. Data is persisted that the user did not intend. This is because we no longer have a snapshot of the browser cached state at that time. I hope this makes sense. If not, I can clarify. Thanks. ... By the way, a workaround in regards to updating parent conversation state you can always use a non-Seam POJO which maintains mutable state. Any class not annotated with @Name, will not be managed by Seam and thus, will not be reverted back to the outer conversation state when a nested conversation ends. All changes to the internal state of the object will stick in the outer conversation. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4085522#4085522 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4085522 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
A great thank your for writing a response, Jacob! I already felt that most users on this forum aren't interested and don't care about the feature request, even though it's a feature not freshly conceived by me, but a feature which is already available and proven in Spring Web Flow. I'll read your post later this evening and then think about your use of nested conversations (the master-detail editing). Perhaps I'll understand then why the output-mapper function still misses in Seam. PS: Your workaround for transferring state to the parent conversation state, with a non-Seam POJO placed in parent conversation scope, is smart. One of the simple workarounds I tested was to fake a write access to the parent conversation at the end of a nested conversation. This can be done, given that the underlying store for the Conversation context is the Session scope (entries for a certain conversation are stored with a special generated key that includes the conversation id). If we know the format of this key and generate this key ourselves, we can write to the parent conversation scope. It should only be kept in mind that by doing this we completely bypass Seam's support for Entity passivation (when an entity instance or a collection of entity instances is regularly saved in conversation scope, ie. not with the described fake write, Seam wraps the Entity instance into a special wrapper class such as org.jboss.seam.contexts.EntityBean or org.jboss.seam.contexts.EntityBeanList and then saves this wrapper class instance). View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4085545#4085545 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4085545 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
wschwendt wrote : A great thank your for writing a response, Jacob! Sorry, I have to sell an 'r'. It should read: A great thank you_ for writing a response, Jacob! View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4085546#4085546 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4085546 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
No problem. I would welcome any input from other forum members as well. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4085592#4085592 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4085592 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
jacob.orshalick wrote : | If a single long-running conversation was used, you end up submitting addresses that were not intended by the user (at least not what they saw on the browser-cached edit screen) since the Person was updated in the conversation context. If the conversation is nested for the Address details screen, the addition of addresses does not affect the outer conversation. In other words, we have a snapshot of state prior to adding the Addresses. | Hi Jacob, I wonder if you could explain this a little more; I don't completely follow. It seems to me that if you have a (managed) Person entity in the parent conversation, and (in a nested conversation) you add an address to it (something like person.addAddress(newAddress) ), the newAddress will not be directly in the parent conversation, but it will be directly referenced by Person, which is in the parent conversation. And thus entityManager.flush() would cause newAddress to be persisted, even if the user backbuttons out of the nested conversation. So, I'm guessing you're not doing a person.addAddress(newAddress) kind of thing. What are you doing? Thanks for the posts, guys! I think nested conversations need to be discussed more. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4085645#4085645 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4085645 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
Hi Matt, Thanks for the response! Actually I am doing a Person.setAddresses(listOfAddresses) when the Address details page is submitted. This sets the list of addresses for the Person in the nested conversation not affecting the parent conversation. The reason is that Seam has taken a snapshot of my Person entity in the outer conversation on nesting (which didn't have the new addresses). The original Person instance will be reverted back to should the user back up to the original edit Person screen and submit. Seam retrieves the outer conversation by id on submit and restores the state of my Person object at the time of the snapshot which doesn't include the new addresses. I hope that clarifies the scenario a little bit... You bring up an interesting point with respect to the EntityManager. I will have to test this point using the Seam managed persistence context. I do not know the effects of nesting on the Seam managed persistence context and whether it is included in the state snapshot. Currently my implementation does not require a Seam managed persistence context as we always perform a fetch join when dependent objects are needed and merge() on final submit. Thus, I am keeping my entities within the scope of the conversation context. This ensures that nesting the conversation will maintain a state snapshot of my entity in the outer conversation context regardless of changes to the entity in the nested conversation. Maybe an expert on the effects of nested conversations on a Seam managed persistence context could shed some light on this? View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4085669#4085669 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4085669 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
wschwendt, Thanks for the information. Yes, I understand how the Seam managed persistence context works, in theory. I suppose my question relates more to how the Seam managed persistence context maintains managed entities with respect to nested conversations... So if I have an entity in my outer conversation, say Person as before. I loaded my Person instance in the outer conversation with a Seam managed persistence context which means my Person instance remains managed for the course of the conversation. Now I navigate to the Address details page which nests a conversation, 1. Does the snapshot of the Conversation context include a snapshot of the *managed entity*? 2. If I make changes to the Person in the nested conversation, since this is a *managed entity* does it make any difference in the semantics of the outer vs. nested conversation? 3. Will I still be able to revert back to the outer conversation snapshot of my Person object as I can with a detached entity? I will have to create an example that tests this behavior with attached entities as I know it works with detached entities. If anyone could provide any insight, that would be great. Thanks again. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4085745#4085745 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4085745 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
Jacob, as for my previous post, I wrote it as some sort of summary a further discussion can be based on. This also allows other readers to follow this thread more easily. As for your other questions, I have to think about some things first before I can write a follow-up post that tries to address these other issues. Regards, Wolfgang View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4085766#4085766 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4085766 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
anonymous wrote : if I think of breadcrumbs and the conversation stack (- 6.7.5. Breadcrumbs), the use of nested conversations goes into a direction much similar to the composition of subflows This is a good point, and I have discussed this at length with my colleagues. But, if you think of nested conversations as continuations (http://www.brainbell.com/tutorials/java/Continuation_Servers.htm), the implementation of the Seam conversation model suddenly makes perfect sense. I actually posted the breadcrumb issue you raise as a topic: http://www.jboss.org/index.html?module=bbop=viewtopict=118894 Actually, simply filtering the ConversationStack by view-id yields the expected results from breadcrumbs with the continuation view of nested conversations. I can post the filtering code if you or anyone is interested. It is simply a component that wraps the ConversationStack. I will soon be posting an extended seam-booking example with an accompanying article that will illustrate the continuation approach in-depth. View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4085811#4085811 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4085811 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
By the way, I didn't realize this: wschwendt wrote : And the following approach is not viable either: We cannot simply access a component from the parent conversation and call a property Setter of this component with the ending result of the nested conversation supplied as argument for this Setter.The reason is that when a component from the parent conversation is called while the nested conversation is still in progress, the ManagedEntityIdentityInterceptor saves wrappers for the called component in the scope of the nested conversation (!) and not the scope of the parent conversation. So once the nested conversation scope gets destroyed at the end of the nested conversation, the saved wrappers for the component from the parent conversation get destroyed as well. | | I can't help but think this wasn't intended; I'm guessing ManagedEntityIdentityInterceptor is intended to be transparent. (Side rant: it's not transparent, and has caused me some pain.) View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4085815#4085815 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4085815 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
[jboss-user] [JBoss Seam] - Re: Feature request regarding nested conversations
Very interesting thread. i like to give a new usecase (or workflow) We have a search screen, where the user can search for an object(e.g. an experiment) When navigation to the show/edit screen ocurs a conversation is started and the object(the experiment) is shown. Now the user can work with the object(the experiment) What comes in now is a subworkflow. This workflow uses a nested conversation and could be started on any page. When this subworkflow ends, the nested conversation ends and redirection to the starting page occurs. Now imagine that our object(experiment) consists of many parts (analysis,mtplate,samples and so on). Could it be good design to create some of this parts in a subworkflow? And if so, how can i get hold of the assembled object in my outer conversation? This gets more complex when you are aiming to an object hierarchy An experiment has mtplates and analyses. Now when editing an analysis, this analysis has to be associated with an mtplate. But if none exist, it must be created. After creation of the mtplate there is no connection between analysis and the created mtplate because the mtplate belongs to the experiment. I hope you see my point. My question is how this kind of workflows can be correctly implemented with seam and conversations? For now, it seems to me that it is nessacary to deliver results from the nested conversation to the outer conversation. Ciao, Carsten View the original post : http://www.jboss.com/index.html?module=bbop=viewtopicp=4085852#4085852 Reply to the post : http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4085852 ___ jboss-user mailing list jboss-user@lists.jboss.org https://lists.jboss.org/mailman/listinfo/jboss-user
