Comments on: Understanding Nested Conversations http://www.andygibson.net/blog/article/understanding-nested-conversations/ Open Source Projects & Technical Writings Fri, 30 Jul 2010 20:20:39 +0000 http://wordpress.org/?v=2.9.2 hourly 1 By: Andy Gibson http://www.andygibson.net/blog/article/understanding-nested-conversations/comment-page-1/#comment-14364 Andy Gibson Mon, 08 Feb 2010 06:47:30 +0000 http://www.andygibson.net/blog/?p=778#comment-14364 Apologies for the delay in the reply, things have been busy. The biggest problem you have is that your data changes must take place in a separate conversation since nested conversations share the same persistence context with its parent. You need to be able to make those changes to the data and persist them in the span of a conversation. This should help define how your flow goes. If you start on the search form, and select items and go to the listing form, that could be one conversation so you can keep that state separate. Then you could click the link to make the changes to the data and that propagates no conversation, but, it does pass in the conversation Id that the selection and listing runs under. This way, you can start a brand new conversation containing the data editing, and you can end that conversation, commit the data changes, and go back to your search page by going back to the listing page and manually adding the conversation Id that was passed in when you started the editing process. I might have to create a new post to explain this a little better since it also gets around the issue of not having a Persistence Context per nested conversation. Oh, and one big page flow probably won't work since the conversation lasts as long as the flow and all the data changes will build up in the same flow. I'm going to have a think about this and maybe do a post to reflect my thoughts a little better, Cheers, Andy Apologies for the delay in the reply, things have been busy. The biggest problem you have is that your data changes must take place in a separate conversation since nested conversations share the same persistence context with its parent. You need to be able to make those changes to the data and persist them in the span of a conversation. This should help define how your flow goes. If you start on the search form, and select items and go to the listing form, that could be one conversation so you can keep that state separate. Then you could click the link to make the changes to the data and that propagates no conversation, but, it does pass in the conversation Id that the selection and listing runs under. This way, you can start a brand new conversation containing the data editing, and you can end that conversation, commit the data changes, and go back to your search page by going back to the listing page and manually adding the conversation Id that was passed in when you started the editing process.

I might have to create a new post to explain this a little better since it also gets around the issue of not having a Persistence Context per nested conversation. Oh, and one big page flow probably won’t work since the conversation lasts as long as the flow and all the data changes will build up in the same flow.

I’m going to have a think about this and maybe do a post to reflect my thoughts a little better,

Cheers,

Andy

]]> By: Geraldo Luiz http://www.andygibson.net/blog/article/understanding-nested-conversations/comment-page-1/#comment-14345 Geraldo Luiz Tue, 26 Jan 2010 02:29:01 +0000 http://www.andygibson.net/blog/?p=778#comment-14345 Dear Andy, I was working on a use case that begins with the user selecting a menu option that led him to a query view. Then a list of entities is shown and he selects some and chooses actions on them (like delete, update something, modify some attributes, and so on). Any option can lead to other sub views, with specific attributes. After performing the action, the user can go back (using the browser back button which is a little problematic, with ajax issues in updating the view on some browsers and all - btw I think you should write a post someday about it) to the list to select some other row or choose to perform another action on them or go back to the query view to make another query or to go back to the menu to choose another option. So many possible paths. I had a helluva time figuring out how to estabilish @begin and @end conversation points in this scenario, that is not so unusual. The hotel booking sample has a very straight and clear path so it's easy to see the conversation boundaries, but what is the best approach when the things get a little more complicated with multiple possible paths? May the page flow strategy be a feasible solution is this case? Thanks, Geraldo. Dear Andy,

I was working on a use case that begins with the user selecting a menu option that led him to a query view. Then a list of entities is shown and he selects some and chooses actions on them (like delete, update something, modify some attributes, and so on). Any option can lead to other sub views, with specific attributes.

After performing the action, the user can go back (using the browser back button which is a little problematic, with ajax issues in updating the view on some browsers and all – btw I think you should write a post someday about it) to the list to select some other row or choose to perform another action on them or go back to the query view to make another query or to go back to the menu to choose another option. So many possible paths.

I had a helluva time figuring out how to estabilish @begin and @end conversation points in this scenario, that is not so unusual.

The hotel booking sample has a very straight and clear path so it’s easy to see the conversation boundaries, but what is the best approach when the things get a little more complicated with multiple possible paths?

May the page flow strategy be a feasible solution is this case?

Thanks,

Geraldo.

]]> By: Andy Gibson http://www.andygibson.net/blog/article/understanding-nested-conversations/comment-page-1/#comment-14334 Andy Gibson Fri, 15 Jan 2010 03:54:28 +0000 http://www.andygibson.net/blog/?p=778#comment-14334 Hi Andy, Yes, that is a useful side effect of nested conversations! I tend to use page flows since it constrains the navigation a user can make, and you don't have to worry about them going to some other page that will begin a conversation with join=true and the new page ends up running in your old nested conversation. Not a problem though if you have conversation pages with no/few links on them for the user to click on that will take them outside your current conversation. Regarding component design, for my needs, which is mostly searching and CRUD, I use the EntityHome and EntityQuery components and generally have one per CRUD or search page respectively. I tend to keep things like factory methods related to the pages in the entity home bean and entity query associated with the page. Seam with its statefulness really does remove the need for Dao type components, although for more complex data, sometimes a dao type of 'data producer' is still needed when the data fetch is more complex. For action listeners and responding to user events, typically I do that in the entity home beans also. Again, there are few places where you will end up using that bean, and I have yet to use an Entity Home bean for anything other than the page that displays the entity details and the page that lets you edit the entity. I tend not to build large hierarchies with big plans for reuse since most code can be refactored later on as needed and most code doesn't offer much opportunity for reuse. This offers a nice balance between being an architect astronaut and having a bad design. Just keeping it open for refactoring is probably more important than spotting places for patterns and reuse the first time around. Saying that, with todays tools, it is pretty much impossible to not be able to refactor, so I guess the real trick is to only write applications with files your IDE can refactor! Cheers, Andy Gibson Hi Andy,

Yes, that is a useful side effect of nested conversations! I tend to use page flows since it constrains the navigation a user can make, and you don’t have to worry about them going to some other page that will begin a conversation with join=true and the new page ends up running in your old nested conversation. Not a problem though if you have conversation pages with no/few links on them for the user to click on that will take them outside your current conversation.

Regarding component design, for my needs, which is mostly searching and CRUD, I use the EntityHome and EntityQuery components and generally have one per CRUD or search page respectively. I tend to keep things like factory methods related to the pages in the entity home bean and entity query associated with the page. Seam with its statefulness really does remove the need for Dao type components, although for more complex data, sometimes a dao type of ‘data producer’ is still needed when the data fetch is more complex. For action listeners and responding to user events, typically I do that in the entity home beans also. Again, there are few places where you will end up using that bean, and I have yet to use an Entity Home bean for anything other than the page that displays the entity details and the page that lets you edit the entity.

I tend not to build large hierarchies with big plans for reuse since most code can be refactored later on as needed and most code doesn’t offer much opportunity for reuse. This offers a nice balance between being an architect astronaut and having a bad design. Just keeping it open for refactoring is probably more important than spotting places for patterns and reuse the first time around. Saying that, with todays tools, it is pretty much impossible to not be able to refactor, so I guess the real trick is to only write applications with files your IDE can refactor!

Cheers,

Andy Gibson

]]> By: Andy http://www.andygibson.net/blog/article/understanding-nested-conversations/comment-page-1/#comment-14331 Andy Wed, 13 Jan 2010 16:43:43 +0000 http://www.andygibson.net/blog/?p=778#comment-14331 Hi Andy, Thank you a lot for sharing your view on conversation aspect of the Seam. It really helps to form a rich and full picture of the term. Regarding the nested conversation I find it very useful from navigation prospective in a use case when one need to do a lookup for an input on the main conversation by redirecting to a dedicated search page. When value is selected and nested conversation is ended it will automatically restore the parent conversation, so no need to keep track of what the calling page was. It would be interesting to know you opinion on components design: backing beans vs action beans (well, seam components), the granularity and degree of reuse. Thanks a lot for your blog. Andy Z. Hi Andy,

Thank you a lot for sharing your view on conversation aspect of the Seam. It really helps to form a rich and full picture of the term.

Regarding the nested conversation I find it very useful from navigation prospective in a use case when one need to do a lookup for an input on the main conversation by redirecting to a dedicated search page. When value is selected and nested conversation is ended it will automatically restore the parent conversation, so no need to keep track of what the calling page was.

It would be interesting to know you opinion on components design: backing beans vs action beans (well, seam components), the granularity and degree of reuse.

Thanks a lot for your blog.

Andy Z.

]]>