Ticket #173 (closed Enhancement: fixed)
Hook code as object
Reported by: | jri | Owned by: | jri |
---|---|---|---|
Priority: | Major | Milestone: | Release 4.1 |
Component: | DeepaMehta Standard Distribution | Version: | 4.0.6 |
Keywords: | Cc: | ||
Complexity: | 5 | Area: | API |
Module: |
Description
The client-side extension mechanism should be redesigned as follows: instead of providing hook code as distinguished methods there should be a handler registry. The registry would be used by plugins to register their hook code. Hook code would be represented as an object (that encapsulates the handler function) of its own. Thus, the hook code could be further attributed, e.g. by a "priority" value. The priority value would control the plugin execution order on a per-hook basis. Thus, this refactoring would provide the basis for the "Channelling facility for competing plugins" (see #168).
Another advantage of this design would be performance improvement. For hook triggering the framework would no longer iterate over *all* installed plugins but trigger the registered handlers directly.
This design would be also applicable to the server-side (not covered by this ticket).
Change History
comment:2 Changed 13 years ago by Jörg Richter
Plugin handler registry Pt.2 (#173).
Adapt all the modules to new handler registry design.
See ticket 173.
comment:3 Changed 13 years ago by jri
Client-side hook code is no longer placed in distinguished methods but explicitly registered at the Webclient.
IMPORTANT: plugin developers must adapt their hook code.
Example (topic_commands hook): change ...
this.topic_commands = function(topic) {...}
to
dm4c.register_plugin_handler("topic_commands", function(topic) {...})
This transformation is a no-brainer (don't forget the trailing parenthesis).
The hook name is specified as a string.
For a list of the available Webclient hooks see the hook_names object in plugin_manager.js (Webclient module).
comment:4 Changed 13 years ago by Jörg Richter
Plugin handler registry Pt.3 (#173).
Handlers for hooks defined by a plugin can be registered *before* that very plugin is loaded.
So, no hook-existence check is performed at registration time.
For plugin developers this simplifies the situation when a plugin uses hooks defined by other plugins.
Consider this situation:
1) The Topicmaps plugin defines the "topicmaps_renderer" hook.
2) The Geomaps plugin uses that hook to provide a custom renderer.
3) At Topicmaps initialization time all renderers must be available.
See ticket 173.
comment:5 Changed 13 years ago by Jörg Richter
Plugin handler registry Pt.2 (#173).
Adapt all the modules to new handler registry design.
See ticket 173.
comment:6 Changed 13 years ago by Jörg Richter
Plugin handler registry Pt.3 (#173).
Handlers for hooks defined by a plugin can be registered *before* that very plugin is loaded.
So, no hook-existence check is performed at registration time.
For plugin developers this simplifies the situation when a plugin uses hooks defined by other plugins.
Consider this situation:
1) The Topicmaps plugin defines the "topicmaps_renderer" hook.
2) The Geomaps plugin uses that hook to provide a custom renderer.
3) At Topicmaps initialization time all renderers must be available.
See ticket 173.
comment:7 Changed 13 years ago by jri
- Status changed from accepted to closed
- Resolution set to fixed
The priority mechanism is not yet realized.
See #168