Blueprint: Unified Hook and Signal Slot Registration
|Proposal||Determine a concrete hook definition and registration within Packages|
|Status||Draft, Discussion, Voting Phase, Accepted, Declined, Withdrawn|
|Current Progress||Unknown, Started, Good Progress, Bad Progress, Stalled, Review Needed|
|Topic for Gerrit||###gerrit_topic###|
- Brainstorming started during TYPO3 CMS 7 development
- Implementation is set for v7.3 (once we agreed on the idea)
Goals / Motivation
The TYPO3 Core uses Hooks and Signal Slots in more than 30 ways, some are improperly configured (Design Pattern of Signals should not modify anything) and have different syntax most of the time. The names of the hooks are outdated. Additionally all hooks are registered at runtime on the global array $TYPO3_CONF_VARS['SC_OPTIONS'] in ext_localconf.php. A common place for registering and calling hooks should be implemented. Same goes for Signals. This way the caching of the hooks is separated from the rest of the logic in ext_localconf.php.
A main class named "HookManager" that loads and caches all hooks that are registered, thus takes all PHP files based on Configuration/Hooks/* which return arrays with the information about a hook (a name / ID of the hook, currently SC_OPTIONS.... but can be replaced to something else) and a "getItemsForHook($hookId)" which returns all items where the hook can actually do what he wants with them. At a later step this could be even improved to have the HookManager call the hookItems directly.
It is still open if the registration is "Configuration" or something else, as callback functions could be registered as well.