Mario Ivankovits wrote: > Sure, as Werner wrote the "conversation" state handles all we need - at > least i hope so, I am close before to jump to seam. > But - as far as i understand - even seam only works successfully if you > design your beans to always request database-data > using the entitymanager. > So the main advantage seam provides is to handle the > "(database)session-per-application-transaction" > in a sophisticated way. >
I have not looked to deep into seam yet, but having to use data requests to have the conversation scope to work, does not seem to be really mandatory, and the docs do not indicate that. You get opensessioninview and transactional handling optionally if you need it, but the usage of data access for gaining a conversation scope does not seem mandatory to me and does not make sense. > Its still save, and I would say necesssary to use e.g. saveState when > you have to pass application-states (NOT pojo instances) > from one http-request to another. I mean values sort of "current", e.g > current order-number, current item-id, ... > Not really necessary, you can keep the app states within the conversation sort of as model values and have them injected and outjected as far as I understood the papers. But this is sort of a wild guess since I have not had time to look deeper into seam than reading the paper and trying the examples. > Those values often have to live after a conversation ended, but putting > them in session scope is still too broad. > Well savestate sort of is a conversation of its own, but you are right, it could make sense in this case, but also you could push the data into another conversation with a longer scope. But have in mind, seam seems to be able to cover the double opened window problem according to the docs, savestate definitely is not. (and neither is my scope component at the current time which I nailed recently into the sandbox)
