16 lines
1.7 KiB
Plaintext
16 lines
1.7 KiB
Plaintext
|
So, a plugin is an npm package whose name starts with ep_ and that contains a file ep.json
|
||
|
|
require("ep_etherpad-lite/static/js/plugingfw/plugins").update() will use npm to list all installed modules and read their ep.json files. These will contain registrations for hooks which are loaded
|
||
|
|
A hook registration is a pairs of a hook name and a function reference (filename for require() plus function name)
|
||
|
|
require("ep_etherpad-lite/static/js/plugingfw/hooks").callAll("hook_name", {argname:value}) will call all hook functions registered for hook_name
|
||
|
|
That is the basis.
|
||
|
|
Ok, so that was a slight simplification: inside ep.json, hook registrations are grouped into groups called "parts". Parts from all plugins are ordered using a topological sort according to "pre" and "post" pointers to other plugins/parts (just like dependencies, but non-installed plugins are silently ignored).
|
||
|
|
This ordering is honored when you do callAll(hook_name) - hook functions for that hook_name are called in that order
|
||
|
|
Ordering between plugins is undefined, only parts are ordered.
|
||
|
|
|
||
|
|
A plugin usually has one part, but it van have multiple.
|
||
|
|
This is so that it can insert some hook registration before that of another plugin, and another one after.
|
||
|
|
This is important for e.g. registering URL-handlers for the express webserver, if you have some very generic and some very specific url-regexps
|
||
|
|
So, that's basically it... apart from client-side hooks
|
||
|
|
which works the same way, but uses a separate member of the part (part.client_hooks vs part.hooks), and where the hook function must obviously reside in a file require():able from the client...
|
||
|
|
One thing more: The main etherpad tree is actually a plugin itself, called ep_etherpad-lite, and it has it's own ep.json...
|
||
|
|
was that clear?
|