Hi Henrique,
I think there is a cycle risk if we call recursively but this can be eliminated
by imposing a restriction to call only a single time a notification on a
particular object.
The handling seems to be done in ERXEnterpriseObject, lines 72-74, I suggest
somethings like this to handle the cascading of these notification :
NSMutableSet notifedInsertedObjects = new NSMutableSet
NSMutableSet notifedIUpdatedObjects = new NSMutableSet
NSMutableSet notifedIDeletedObjects = new NSMutableSet
boolean notificationCompleted = false;
while (notificationCompleted == false) {
NSSet newInsertedObjects = new
NSSet(ec.insertedObjects())setBySubtractingSet(notifedInsertedObjects);
... for updated and deleted objects
if (newInsertedObjects.isEmpty() && newUpdatedObjects.isEmpty() &&
newDeletedObjects.isEmpty() {
notificationCompleted = true;
}
ERXEnterpriseObject.WillInsertProcessor.perform(ec, newInsertedObjects);
notifedInsertedObjects.addAll(newInsertedObjects);
... for updated and deleted objects
}
The didXXX does not have this problem since the save is done and the objects
are all known.
> Le 2015-08-11 à 16:22, Henrique Prange <[email protected]> a écrit :
>
> Hey guys,
>
> I’ve been using Wonder’s augmented transaction methods in combination with
> notifications to encourage a loosely coupled design. Over time, I've been
> increasingly applying this kind of solution on my systems. Now, I'm facing a
> problem when expecting to produce notifications for recurring EO changes.
> Basically, I expect the invocation of the willUpdate method on a second EO
> changed during the willUpdate phase of a former EO. However, in that
> scenario, the second EO willUpdate method is never invoked.
>
> I've seen that the CooperatingEditingContext described in the Practical
> WebObjects book does exactly what I want. So, is there a reason to not
> support notifications for recurring changes (i.e. avoid notification cycles)?
> Is the current behavior expected? Or is it a misbehavior?
>
> Cheers,
>
> Henrique
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Webobjects-dev mailing list ([email protected])
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/webobjects-dev/samuel%40samkar.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:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
