Ticket #173 (closed Enhancement: fixed)

Opened 9 years ago

Last modified 8 years ago

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:1 Changed 9 years ago by jri

  • Status changed from new to accepted

comment:2 Changed 9 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 9 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 9 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 9 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 9 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 8 years ago by jri

  • Status changed from accepted to closed
  • Resolution set to fixed

The priority mechanism is not yet realized.

See #168

comment:8 Changed 8 years ago by Jörg Richter

Webclient: change listener API (#173).

Rename method:

    dm4c.register_plugin_handler -> dm4c.register_listener

"Listener" is the more telling wording.

Developers must adapt their plugins.

See ticket 173.

Note: See TracTickets for help on using tickets.