Adding custom event (for example, How-to with Quip)

I didn’t find this info written, and the logic of function getEventMap in the core is fuzzy, so I post "how-to" and at the same time ask if there’s another way..

Events+Plugins are great for activity stream, notification,etc.. But, for example in Quip commenting addon, there are no built-in events. This is a simple example for "OnQuipCommentDelete", but works the same for whatever...

1.Add this code last thing before the return in: core\components\quip\processors\web\comment\remove.php



2. I manually added this to the database:


*Note: the "service=1" and groupname="" logic came from reading this weird line in core\model\modx\modx.class.php, function getEventMap.


3. Create the plugin:
name: sample
System Events: OnQuipCommentDelete
code:


in the above example, after comment deleted successfuly - redirect to page (where thread holds the document id, future Quip will probably use the parent as id..)




Now, the question:
I saw in Discuss svn you used hooks: $modx->hooks->load(...), added to deprecated-feeling of getEventmap, I get a feeling custom events should follow the discuss’s hooks-way?

If not - what’s up with this service number, and why not allow custom groupname ("Quip").

Thanks.

That should be on the documentation for MODx Revolution’s How to tutorials.

Thanks oori.

Component-specific events are more efficient if implemented using a custom approach like Quip uses because MODx events are global and thus are executed on every request. If you add custom events for every component you use on a site, that will quickly degrade the performance of the core.

But, say with the above quip example, the event will only be called by invokeEvent in the quip comment remove processor. and then, a plugin will only process it if it has this event marked in system events.
where exactly is the efficiency compared to the custom approach?
you say: "every request" - you mean anything else then what i just wrote?
(note, that example is not an "onRender" kind of plugin that runs on content view... it’s an action related plugin. (in this sense, same as the discuss notification).



Ah, wait - "the performance of the core" - not of the SITE. So - the sub-text of this is that events imlpamentation in the core is "ok ok" or what?

In the above quip example - could you please elaborate on how using events+plugins VS. custom-discuss-style-hooks affects the performance (and of what) ?


BTW, in your reply your wrote: "using a custom approach like Quip", you meant Discuss, right? Quip has none...

Any plugins registered to your events would be loaded into the context cache of every context in the system. I just feel anything that is not global to the execution of the core should be isolated to the component in question.

And yes, I meant Discuss.

Agreed.

If you can do this with a snippet call or ajax call that is pretty much stand alone -- it would be much better for everything.

In my experience, if I build an application with the expectation that 100k people are going to use it at once, I will streamline it more up front.