Re: Solved Notification or handler after an EO got snapshot update
Re: Solved Notification or handler after an EO got snapshot update
- Subject: Re: Solved Notification or handler after an EO got snapshot update
- From: Samuel Pelletier <email@hidden>
- Date: Mon, 24 Mar 2014 10:04:31 -0400
Hi,
Finally after some stack inspection, I found a good hook: public void clearProperties() is called when the DatabaseContext default an object modified in another EO to reset the relationships.
It is also called when finalizing the object.
Maybe not the name I was searching but the right event.
Samuel
Le 2014-03-21 à 18:18, Ray Kiddy <email@hidden> a écrit :
> On Fri, 21 Mar 2014 09:18:46 -0400
> Samuel Pelletier <email@hidden> wrote:
>
>> Hi,
>>
>> I have a class where I added an ivar to keep a cache of some values
>> extracted from toMany relationships. I want to clear this cache if
>> the toMany is updated from another editingContext but I do not find a
>> proper way to catch this event.
>>
>> For simple attributes, creating a "public
>> void_setAtributeName(ValueClass value)" method works but this is not
>> called for toMany relationships. The EOEnterpriseObject method "void
>> updateFromSnapshot(NSDictionary<String,Object> snapshot)" has a
>> promising name but is not called.
>>
>> Is there a way to trap this event, either with a notification or a
>> method overrides? Something like "didUpdateFromSnapshot" would be
>> wonderful.
>>
>> Samuel
>>
>
> You are only looking at the highest level of objects in EOF.
> Almost everything in EOF can be done in multiple places, the EOControl
> classes/delegates, the EODatabase/EODatabaseContext classes/delegates,
> and the EOAdaptor/EOAdaptorContext classes/delegates. Almost everything
> is reachable from all of these, though things look different at each
> level.
>
> You are talking about snapshots, so this is probably in the
> EODatabaseContext delegates. But I am not sure whether you want
> databaseContextDidFetchObjects or databaseContextShouldFireArrayFault,
> for example, or one of the others.
>
> Also, in any given situation, more than one of the delegate methods will
> be called, and it is not always clear in what order they are called and
> where you want to do your thing.
>
> The nice thing about delegates is that you can implement them all (so
> that their actions are innocuous) and log something from each. Then run
> your code and see what is actually called when. You can even have code
> that implements all of these sitting around, ready to be pasted into
> some random class.
>
> If you become comfortable with using delegates instead of overriding
> methods, I suggest that you will find it to be more flexible and
> powerful in the long run. Just spend some time with the javadoc for
> all the Delegate classes and you will see how much can be done with
> them.
>
> cheers - ray
> _______________________________________________
> 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