-
1. Re: Understanding... Bijection
gavin.king Oct 5, 2006 4:15 PM (in response to johnurban)Exactly.
-
2. Re: Understanding... Bijection
gus888 Oct 5, 2006 5:42 PM (in response to johnurban)Hi Gavin,
I have a quesion about the @In in the issues example. I found there are two ways for @In injection. One way is @In a SFSB into another SFSB to pass values and invoke the second SFSB, the other way is @In a SFSB into a SLSB, then pass values into a second SFSB and invoke the second one, the SLSB works a bridge. The two @In ways works as same? Thank you in advance. -
3. Re: Understanding... Bijection
gavin.king Oct 5, 2006 6:18 PM (in response to johnurban)Yes, of course, there is no difference.
-
4. Re: Understanding... Bijection
gus888 Oct 5, 2006 6:33 PM (in response to johnurban)Hi Gavin,
At the beginning, I thought @In a SFSB into another SFSB will use more memory than the second one (SFSB -> SLSB -> SFSB). If it works same, I prefer the first (SFSB -> SFSB), since I don't need to create the extra SLSB. Is it correct? Thank you very much. -
5. Re: Understanding... Bijection
jazir1979 Oct 12, 2006 1:56 AM (in response to johnurban)
Hi all,
My user login process works exactly how "johnurban" described. I have a "desktop" SFSB that gets the "user" injected into it and returns a list of "modules and transactions" that a user can access for building up their menu structure.
However, I have a problem understanding how a user login session can end. Specifically:
1) User from the same browser session hits the login page and logs in with a different username
2) User goes to the desktop but still has the same "desktop" SFSB in their session, causing them to view the wrong information.
I tried to solve this by destroying the session context upon login (before putting the "user" into the session context). However, this totally removes the "desktop" SFSB and causes errors.
Anybody know how I should be doing this?
cheers,
Daniel. -
6. Re: Understanding... Bijection
mnrz Oct 12, 2006 4:50 AM (in response to johnurban)Hi
Do we think of @Out, somehow as setAttribute("variable_name",someValue) method of the session? and also, @In as a getAttribute("variable_name")
Am I right? -
-
8. Re: Understanding... Bijection
jazir1979 Oct 12, 2006 5:59 PM (in response to johnurban)Any suggestions on my problem above?
thanks!
Daniel. -
9. Re: Understanding... Bijection
jjarkko Oct 12, 2006 6:11 PM (in response to johnurban)Regarding the commet about set/get analogy, how does this feel then?
Replace @In with @Get and @Out with @Set to get the analogy more correct..@Get(scope=Session) User user; @Set List <Project> projects;
etc... -
10. Re: Understanding... Bijection
jazir1979 Oct 12, 2006 6:31 PM (in response to johnurban)More info on MY problem:
I believe the booking example suffers from this same flaw, because a user can login again with a different username, without being forced to logout.
The session is only invalidated upon logout...
Steps:
Log in as user 1, make a booking
Go to home.seam and log in as user 2 from same browser session, you will see the booking. -
11. Re: Understanding... Bijection
jazir1979 Oct 12, 2006 7:42 PM (in response to johnurban)NOTE: I fixed this in my app by sending users that are already logged in to their desktop page if they directly request the login page. This will FORCE them to logout and invalidate the session before loggin in again.
Might be nice to add that to the booking example
It was easy for me because I already had a "verifyLoggedIn" action which applies to every request, and I was able to handle the logic there.
If there is a more logical way I should have done this, let me know :)
Dan.