-
1. Re: Design suggestion
patrick_ibg Dec 12, 2005 11:05 AM (in response to manuel.gentile)Seam doesn't support multiple nested conversations at this point.
So for now you have two choices:
1. search query in conversation scope, edit on event scope.
2. search query and edit in the same conversation scope. -
2. Re: Design suggestion
manuel.gentile Dec 12, 2005 12:01 PM (in response to manuel.gentile)maybe i solve my problem.....
i use a dummy properties that i put in the view page. the getter of this properties is marked @Begin....
any time i go to this page i begin the conversation and now i can search----> view edit and review the entity....
whitout any error!!!!
is it possible?????
seem to apper the same effect of a nested conversation (editing) inside a view conversation
:-) -
3. Re: Design suggestion
gavin.king Dec 12, 2005 4:14 PM (in response to manuel.gentile)Better to keep your search results in session scope, IMO.
-
4. Re: Design suggestion
manuel.gentile Dec 13, 2005 10:25 AM (in response to manuel.gentile)Must i set Search SFSB SCOPE Session???
or i just mark the Scope of Entity Searched Session? -
5. Re: Design suggestion
patrick_ibg Dec 13, 2005 7:06 PM (in response to manuel.gentile)Probably not a good idea to scope SFSB to session. You could create a search result object (a real POJO, not an Entity Bean, unless you want to persist your search results which sounds crazy) and put that in the session scope.
-
6. Re: Design suggestion
gavin.king Dec 13, 2005 8:07 PM (in response to manuel.gentile)Why do you think it's bad to put an SFSB in the session? I think that's ok....
-
7. Re: Design suggestion
patrick_ibg Dec 13, 2005 9:04 PM (in response to manuel.gentile)Seems weird...
First of all, it won't be freed up until the session is invalidated or the app takes it out of the session context. Then, I'm not too sure how it will behave wrt activation/passivation.
I think the web layer also does its own bit of passivation/activation and writes objects in the session context to disk (depending on configuration)... maybe this is different when you're running tomcat inside of a J2EE container but I'd rather not muck with that :)
Anyway, I think the real reason is that it's cleaner to think of the web layer as a "client" of the EJB container. -
8. Re: Design suggestion
gavin.king Dec 14, 2005 2:23 AM (in response to manuel.gentile)"patrick_ibg" wrote:
First of all, it won't be freed up until the session is invalidated or the app takes it out of the session context.
Well, that just means you should make sure it isn't too huge and/or configure appropriate passivation. It's a tradeoff of performance vs. usability. You can't make an a priori blanket call on something like that."patrick_ibg" wrote:
Then, I'm not too sure how it will behave wrt activation/passivation.
I think the web layer also does its own bit of passivation/activation and writes objects in the session context to disk (depending on configuration)
All this is perfectly fine. All references b/w the session and the stateful beans are indirected via a local interface and can be reconstructed. Note that this same problem affects conversation scope, since it also "persists" to the HttpSession."patrick_ibg" wrote:
Anyway, I think the real reason is that it's cleaner to think of the web layer as a "client" of the EJB container.
I guess that's a metaphysical argument I don't want to get into, but I'll simply say that I disagree with this understanding of the problem.