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 .......
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.
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 protected])
> Help/Unsubscribe/Update your Subscription:
> http://lists.apple.com/mailman/options/webobjects-dev/kelleherk%40gmail.com
>
> This email sent to [email protected]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
