[TYPO3-v4] "CGL" policy for new hooks?

[Oliver Hader]

Hey Tolleiv,

Am 13.03.11 17:46, schrieb Tolleiv.Nietsch:
> Hi,
> 
> I was just wondering if we should discuss what exactly the policy for
> new hooks is. In https://review.typo3.org/1003 I'm being pushed to use a
> hook which does an additional check against an interface.
> 
> Especially for https://review.typo3.org/1003 I don't consider the
> introduced hook to be relevant for many others and introducing it was
> just a matter of separating workspace stuff from the Core, that's why I
> didn't care about an interface.
> 
> But what's the policy for that? When do we claim interfaces for newly
> added hooks in the Core? (why / why not?)
> 
> I'd personally prefer to have a clear policy because it's just
> disrupting if things get blocked just because *this* has to be discussed
> with every hook request again and again.

Thanks for bringing this up again. Unfortunately it's true that we did
not agree and decide on a common policy here. Each of the methods has
advantages and disadvantages.

1) Interfaces
pro +: clean way of IDE integration and automatic code completion
pro +: no parsing overhead the extract file, class and method from
"EXT:ext/class.tx_ext.php:tx_ext->hookFunction"
con -: breaks if interface will be changed due to the fact that an
important parameter was missing or a new parameter will be added in at
the place where the hook gets called

2) Functions
pro +: very flexible way of extending the hook at any time
pro +: no requirement to (auto-)load the interface definition file
con -: parsing overhead of "EXT:ext/class.tx_ext.php:tx_ext->hookFunction"
con -: developer needs to lookup the code to know which parameters are
supported and passed to the hook

Personally I'd like to see interfaces used for new hooks. The existing
hooks of course will stay with the current implementation (hook object
or hook function).


Concerning the problem with interfaces being changed we can think about
the following (some have been mentioned in this thread already):

a) use array to pass information to the hook

The interace definition:
| interace NewHook {
|   public function execute(array $parameters, CallerObject $caller);
| }

The place where the hook gets called:
| $hookParameters = array('variable' => $variable);
| if (!($hookObject instanceof SomeNewHook) {
|   throw new Exception(
|     $hookObject . ' does not implement SomeNewHook',
|     12345678
|   );
| }
| $hookObject->execute($hookParameters, $this);

Thus a developer still needs to look up that part to check which
parameters are supported.

b) use an own data object to pass information to the hook method

The interace definition:
| interace NewHook {
|   public function execute(NewHookData $data, CallerObject $caller);
| }

The place where the hook gets called:
| /** @var $hookData NewHookData */
| $hookData = t3lib_div::makeInstance('NewHookData')
|             ->setVariable($variable);
| if (!($hookObject instanceof SomeNewHook) {
|   throw new Exception(
|     $hookObject . ' does not implement SomeNewHook',
|     12345678
|   );
| }
| $hookObject->execute($hookData, $this);

With this way the supported parameters are encapsulated in the
"NewHookData" object and easily can be adjusted, the interface
definition stays the same. However a new instance needs to be created.


What do you think?

olly
-- 
Oliver Hader
TYPO3 v4 Core Team Leader

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