[TYPO3-core] Hooks and Signal Slots in TYPO3 6.0

[Tolleiv Nietsch]

Hi,

in general a good idea to favor Signal/Slot implementations where we 
used hooks in the past. But in a large part of the existing hooks the 
actually called functionality is much more attached to the caller than 
what you'd get and want from Signal/Slots.

E.g. using the returned result of a hook-call (e.g. 
typolinkLinkHandler), changing the passed data (e.g. processDatamap_*) 
or interrupting further processing from within the hook-call (e.g. 
processCmdmap_deleteAction) would imho really violate the observer 
paradigm and the aim to decouple things in Signal/Slots.

Cheers,
Tolleiv



Oliver Hader schrieb:
> Hey everybody,
>
> with the name-space changes almost every class in the TYPO3 Core has
> been renamed, however the hook calls still are the same. Previously
> those definitions contained the file path, e.g.
> "t3lib/class.t3lib_tcemain.php", but now would be something different
> like "typo3/sysext/core/Classes/DataHandling/DataHandler.php".
>
> Of course it does not make much sense to just rename every how and thus
> break the backward compatible behaviour on this. Besides that we had
> several different ways to register hooks:
>
> 1) plain hook user functions ($hookObject->$hookFunction)
> 2) hook object with a pre-defined method ($hookObject->doSomething())
> 3) hook object that need to implement a particular interface
> 4) signal-slot-dispatchers
>
> Since I'd like to get rid of the misleading and old path definitions (as
> mentioned above), I'd like to suggest to only use
> signal-slot-dispatchers in the core.
>
> We can introduce a backward compatibility layer for the current
> implementation and deprecate that. All new hooks shall then be
> introduced and used with signal-slots only.
>
> What do you think? What's your impression on this topic?
>
> Cheers,
> Olly

-- 
Tolleiv Nietsch
TYPO3 Core Developer


TYPO3 .... inspiring people to share!
Get involved: typo3.org