Hi,
As I get deeper into using Turbine, I'm trying to workout why the login/logout actions
set the user to an anonymous user?
Is this to make things easier in other parts of the framework - it can assume a user
is always present, it just maybe the anonymous one?
This method is also called to get a shell user during re-instantiation of objects in
the TurbineUserPeer.
The requirement I'm trying to cover is the mixed secure/public screen case and thus in
some screens, eg new user screen, the user is populated [by the SessionValidator, ala
Jyve], but with this anonymous one. I want to be able to detect this and replace it
with a slightly better one, using the supplied new user data. The problem is that
getUser returns a new object each time - so I'd have to rely on some bad smelling code
to see if certain fields are empty or not.
Would it be valid to split this into 2 methods, getShellUser() for the peer case,
which works as per the current getUser and returns a new one each time and
getAnonymousUser() for the login/logout scenario, that returns a fixed known anonymous
user (ie a singleton - set the first time its called and returned upon subsequent
calls - obviously in a threadsafe manner).
I can then test whether the user in the rundata object is the same reference as the
getAnonymousUser() and if so, I can proceed as required.
I'm happy to supply a patch for this - if it is the right way to go?
Regards,
Chris
"There is no spoon"
______________________________________________
FREE Personalized Email at Mail.com
Sign up at http://www.mail.com/?sr=signup
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Problems?: [EMAIL PROTECTED]
