Re: MultiECLockManager
Re: MultiECLockManager
- Subject: Re: MultiECLockManager
- From: Jean-François Veillette <email@hidden>
- Date: Mon, 21 Nov 2005 08:51:48 -0500
Le 05-11-20, à 03:52, David Teran a écrit :
The advantage of a factory method for creating all your own subclass
EC's is that you can modify in one place how EC's are created and
create EC's that are of special use to you. My WKEditingContext
subclass is preloaded with a .user() method that refers to a current
session user EO local instance. Also, you can set default delegates
in the factory method based on the passed param.
this is bad design. Check out ERXThreadStorage. there you can set the
user from the current thread with
ERXThreadStorage.takeValueForKey(user, "user")
ERXThreadStorage.removeValueForKey("user")
do this in session.awake and session.sleep
or if the user is stored in the session object: ERExtensions.session()
does -always- return the session from the current thread. Check out
this method and then you do not need to pollute an editingcontext with
references to a user.
I'm currently using a EC subclass where I've added a dictionary where I
put anything 'contextual' that would be needed for validations and
such. One of the thing I put in that dictionary is the current user.
This allow my 'logic' layer to be totaly independent from the WO (or
not WO at all) context it lives in (think of a db connextion, the
current user is not stored in the client app, it's stored in the server
in a 'context-like' object).
I didn't look at the ERXThreadStorage mechanism, but it seem to me that
since WO is using an undetermined thread to handle a request, I would
need to set that key on session-awake on every R-R-L, which leave the
'logic' layer missing a rather basic contextual information.
I do not see the 'bad design', I must be missing something, please
enlight me !
- jfv
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden