Re: ERXThreadStorage and willUpdate()
Re: ERXThreadStorage and willUpdate()
- Subject: Re: ERXThreadStorage and willUpdate()
- From: David Avendasora <email@hidden>
- Date: Mon, 4 Oct 2010 17:29:58 -0400
On Oct 4, 2010, at 4:40 PM, Kieran Kelleher wrote:
> The only thing not clear to me from your code sample is what editing context your system user is in, or whether you can guarantee that it is in the ec that you are saving .......
Yeah, I simplified too far. That call should have been:
setModifiedBy((SystemUser) ERXThreadStorage.valueForKey(editingContext(), "loggedInUser"));
(I'm also using constants instead of magic strings. :-) )
> Personally, I push the current user EOGlobalID into thread storage in Session.awake(), which means I can clone that thread-storage entry that to background thread's ERXThreadStorage that originate from a request thread. My EOs don't know if they are in a request thread or some other thread not involved in request-response.
That's a great idea. I knew we'd end up with better code by asking!
Dave
> I have a standard static convenience method that looks like this in the user entity class, for example:
>
>
> /**
> * @param ec
> * @return the current user from thread storage
> */
> public static CTUser userInCurrentThread(EOEditingContext ec){
> CTUser user = null;
> EOGlobalID gid = (EOGlobalID) ERXThreadStorage.valueForKey(WKEOGenericRecord.AUDIT_USER_GLOBALID_KEY);
> if (gid != null) {
> user = (CTUser) ec.faultForGlobalID(gid, ec);
> } //~ if (gid != null)
> return user;
> }
>
>
> and then my willUpdate code would look something like this:
>
> willUpdate() {
> super.willUpdate();
> CTUser user = CTUser.userInCurrentThread(editingContext());
> if ( user != null ) {
> setModifiedBy(user);
> }
> }
>
>
>
>
> On Oct 4, 2010, at 4:22 PM, David Avendasora wrote:
>
>> Hi all,
>>
>> We are moving from having to remember to manually set the modifiedBy and modifiedDate values in our EOs when they are modified to overriding willUpdate() and pulling the loggedInUser from ERXThreadStorage.
>>
>> We are overriding willUpdate() in our K12GenericRecord which all our EOs extend.
>>
>> for example (very simplified to get the point across) :
>>
>> willUpdate() {
>> super.willUpdate();
>> setModifiedBy((SystemUser) ERXThreadStorage.valueForKey("loggedInUser"));
>> }
>>
>> As you can see, we are casting the results of the ThreadStorage as SystemUser which itself is a subclass of K12GenericRecord.
>>
>> It seems odd to be importing a subclass into it's own superclass, but it since a SystemUser really is a standard EO and therefor is-a K12GenericRecord, it also seems correct.
>>
>> We're not doing anything horribly wrong here, are we?
>>
>> Dave _______________________________________________
>> 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
>
>
>
_______________________________________________
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