Sadly, the Elgg event system confuses pre and post event handlers. These should really be clearly separated out so that you can respond appropriately (either to prevent an event from occuring or to do something after you know that an event has definitely occured).

As it is you need to read the code to see when the event handler is triggered. Sometimes plugins set a really high priority number in their event handlers (that is a low priority) to try to avoid taking an action for an event that another plugin subsequently cancels.

I take some of the blame for this as I helped to design the pre Elgg 1.0 event system and although Misja Hoebe pointed out the error to the Elgg 1.0 developers, my design error was copied over to the current version of Elgg.

Hi Kevin, many thanks for your answer.

I had already read the code, I asked the question although I had already found that there was no implemented post-delete notification system implemented. It was kind of message in a bottle.

The workaround I found was to decorate the annotated object upon callback with a new attribute:

if ($event == "delete") $annotated_obj->annotationToBeDeleted = $ann->id;

The following processing then has to check for this attribute. It's ugly, but lightweight and understandable.

However it raises a persistence question...

At first I set the attribute to "$ann", not "$ann->id". I got a warning from inside database.php that an object was being curated for SQL instead of a string (the debated "trim()"). The issue is, I thought that as long as I didn't call "save()" on my object, the new workaround attribute would not be inserted in database. It should be a non-persistent attribute.

Does this mean that I am only authorized to create non-object attributes on the fly?

Have I missed something about saving? (I mean, why does it call the database??)
(perhaps I should hack some traces in the elgg engine code...)

Or is it in the part of the code I'm not showing? :-)
(this last question because I'm aware that I may not be providing all the details necessary)

For information, I called unset on the workaround attribute after processing, so the attribute should not be around too long.

I also checked with entity browser (great plugin!), and the workaround attribute doesn't appear anywhere. So I don't think I'm polluting the database with this hack.

[meta: I seems I create my questions here with status "open", but I can't find that anywhere afterwards]

Everything on an entity is persisted, but certainly not for annotations. I'm not sure why you are seeing the warning.

I think the plan for 1.9 or so is to standardize the events with create:before, create:after for all the various events so this isn't a problem anymore.

I guess if I were trying to do this now I would try to register a callback for the shutdown event when informed of the annotation delete. Can't remember if the event system works with anonymous functions.

@Cash: Thanks for answering.

About the persistency... perhaps I wasn't clear. I wasn't annoyed at "persisted annotations", but at a persisted attribute of an ElggEntity subclass instance. I try to use the proper vocabulary so that I'm sure we're talking about the same thing (I may be wrong). I had two issues, first that it was persisted (I didn't call save()), then that it forbid an object and I had to use id.
Honestly, I'm very sorry but I wouldn't have time to build an SSCCE. My workaround works, so I'll let it drop.

About the events: good decision. :-) By then I'll probably need backward compatibility, but still.

I don't understand about the shutdown event. Isn't that a system event? How does it help me update anything after a delete has occured?

Thanks for your answer!