question about conversation scope

[kgoedert]

Hi,

If I have several tabs on a page, all concerning company information, like: on the first tab I have some required data like a name. On the second tab I have information concerning company address (which is not required).

Would it be a good ideia to use conversation scope, considering that the user is able only to fill the first tab information?

Thanks

[jacob.orshalick]

If you need to maintain state between several client requests (which it sounds like in some cases you might) a long-running conversation makes this easy.

[kgoedert]

That was what I was thinking... but then, another question based on this.. how I will control the conversation end if the user doesn´t need to fill the address tab?

[jacob.orshalick]

Seam by default is going to start on conversation when the page loads initially, you simply control whether the conversation is promoted to long-running. If not the conversation is destroyed once the request completes.

You could tell Seam to always promote the conversation to long-running when you company information screen is accessed through pages.xml (there are other ways of doing this as well):

<page view-id="company-information.xhtml" action="#{conversation.begin}" />

Then on the submit method:

...
@End
public void submit() {
 // do submit
}
...

which would end the long-running conversation regardless of whether the company-address view was accessed or not.

This also helps if you have edit scenarios where you have to edit company information. You would definitely want to start a long-running conversation as soon as the data is loaded for editing on access of company-information.xhtml so you can maintain the state of your company instance.

[kgoedert]

Hi,

I guess I´m missing something here... If I start a conversation when I load the company information page and end the conversation when the company data is submitted, won´t I loose the company information when I fill the address information, since I ended the conversation when I submitted the company information?

[jacob.orshalick]

Sorry, I guess I made an assumption about your approach :)

So are you saying that you may submit the company information and then submit the addresses? I was assuming it was an all or one approach, in other words the submit() handles persisting the entire unit of work (company information and addresses if any).

[kgoedert]

Sorry... I didn´t make myself clear...
I have a tab where I have the company info and a submit button for this info.
After this data is submitted another tab shows up where the user can (but is not required to) input address info for the previously submitted company.

[jacob.orshalick]

Okay, now I understand your approach. So the company information is persisted prior to adding address info. Then the address info is persisted if added...

So this becomes a little tricky due to the approach. The difficulty is determining where to end the conversation. If the user simply submits company information and we don't end the conversation (because they may want to add addresses) navigating away from the page would leave the conversation in memory even though the unit of work is complete.

Your current approach is possible, but just wondering if it could be a little easier to manage :)

Would it be possible to include the addresses as an optional part of the unit of work prior to persisting the data? For example, user inputs the company information. User can either submit (which persists company information and ends conversation) or click on the already visible address tab. If the user selects the tab the long-running conversation continues which maintains your state. Then on submit of the address information persist both company information and address information and end the conversation. That way you're sure the conversation is always ended appropriately once the unit of work is complete.

[pmuir]

How about a manual flush mode conversation with two points at which you flush - one when you hit save on the company information, another when they (optionally) hit save on the address information. You may or may not have a defined end point for the conversation - if you do, end it there, otherwise let it timeout.

[jacob.orshalick]

Good point Pete, I just always like to clearly define my end points :)

[kgoedert]

I guess I will change my approach :) to a wizard like.... so I will always have one submit, that submits it all.

Thanks for all your helpful replies

[pmuir]

Jacob, do you mark all your navigation links propagation="end" (or similar)? I've always used a propagation="none" to navigate between areas and left conversations to timeout. But I guess with manual flush mode this is less of an issue.

[jacob.orshalick]

No, I generally do not. I just always try to clearly define units of work within a conversation so that if possible I end the conversation when the user is "done" with an activity (which usually means wizard-style approaches). I also use propagation="none" on navigation as the user may back button to the conversation at any time to resume execution. The conversation may timeout but I do try to give the users some time to continue the conversation if they accidentally navigated away from some activity.

Sorry for hijacking the thread, but I am curious why the issue is any different with manual flush mode? I would think maintaining a detached conversation context instance and merging on submit accomplishes the same thing (except that lazy loading would not be possible). Maybe you are referring to if you merge on every action (which I guess would always flush without manual). Could you shed some light on that? Thanks!

[pmuir]

IIRC it was because without manual flush mode you had to be much more careful about not inadvertently calling an action methods as they all caused flushes. Anyway, this was a while ago when I used to write Seam apps and it made sense at the time. Of course, end the conversation if possible e.g. on a done button, but if the user is halfway through doing something then navigates elsewhere then I would not propagate rather than end the conversation.

I never used detached entities as that defeats the point of conversations/seam IMO.

BTW I'm hoping to really read your other threads about conversations when I have time and I hope we can take some of the lessons back into Seam to make it even better (at least improve the docs!).

[jacob.orshalick]

I never used detached entities as that defeats the point of conversations/seam IMO.

I certainly understand your point here, but there are some things I have been able to do with detached entities that did not seem possible otherwise (e.g. a state snapshot approach). Maybe you could provide some insight on how to accomplish this with managed entities when you read my other threads :)

BTW I'm hoping to really read your other threads about conversations when I have time and I hope we can take some of the lessons back into Seam to make it even better (at least improve the docs!).

Please do, I would really like to hear your input!