ERCStampedEnterpriseObject works well for that.
tb
On Oct 4, 2010, at 5:29 PM, David Avendasora wrote:
>
> 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 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/tbritt%40phigment.org
>
> 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]
