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.
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4086731#4086731
Reply to the post :
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?
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4086736#4086736
Reply to the post :
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
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
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
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.
View the original post :
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
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,
Good point Pete, I just always like to clearly define my end points :)
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4086875#4086875
Reply to the post :
http://www.jboss.com/index.html?module=bbop=postingmode=replyp=4086875
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
View the original post :
http://www.jboss.com/index.html?module=bbop=viewtopicp=4086876#4086876
Reply to the post :
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.
View the original post :
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
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
[EMAIL PROTECTED] wrote : 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).
14 matches
Mail list logo
