[RFC|Merged] General Hook Architecture of phpBB3.1

[MichaelC]

Related discussion: https://gist.github.com/26dc674c0062f128c1ab

[Oleg]

I redid template events over the new dispatcher pr.

Currently https://github.com/p/phpbb3-ext-php-hoo ... 452d14fb00 is required for listeners to work.

I am interested in ideas for how to restore our previous API for the listeners.

(03:11:49) rxu: nn- : we could use class_alias() probably to keep names in phpBB namespace
(03:12:13) nn-: it's not just class name though, there is also the function name that must match symfony's
(03:12:36) nn-: good point on class_alias still
(03:12:41) nn-: haven't thought of that
(03:16:03) rxu: for aliasing function we'd need to create a simple wrapper, I'm not sure that's viable thing though
(03:16:20) rxu: ok, that's useless
(03:16:28) nn-: why not? is it going to work?
(03:17:00) rxu: getSubscribedEvents() has to be implemented in child class I guess
(03:17:07) rxu: with exact name
(03:18:02) rxu: so we'd need to implement getSubscribedEvents() and wrapper at the same time
(03:18:08) rxu: that would work
(03:19:13) nn-: so an abstract class then?
(03:19:24) nn-: which extensions would extend instead of implementing symfony's interface?
(03:24:18) rxu: probably yes, to operate with phpBB namespace instaed of Symphony's one
(03:26:39) rxu: and if it won't make the code senselessly overcomplicated

[Oleg]

My todo list here:

1. Rename RUNHOOKS to EVENT
2. Rename everything else from hooks/ledges to listeners/events
3. Add an acp template event
4. Investigate reinstating our underscored api on top of camelcased event dispatcher
5. Investigate renaming of event/*_subscriber to listener/*_subscriber or something along those lines.

[Oleg]

Deciding on a new and improved api for events:

$vars = array('page_title');
$event = 'core.index';
extract($phpbb_dispatcher->dispatch($event, compact($vars), $vars));

[igorw]

What I don't like about this is that it is no longer using the standard EventDispatcher API provided by Symfony.

[rxu]

Just for the record, a common idea for extracting previously compacted variables into globals: https://gist.github.com/2113808

[naderman]

What I don't like about this is that it is no longer using the standard EventDispatcher API provided by Symfony.

Not sure what the problem with that is? Nothing wrong with wrapping the dispatcher or creating a specialisation (kind of what inheritance is for ) for phpBB? If we're going to put these all over the place, it would certainly be nice if it was concise.

[naderman]

Just for the record, a common idea for extracting previously compacted variables into globals: https://gist.github.com/2113808

We do not want to extract them into globals. We want to extract them into local variables in the scope of the function which triggers the event.

[rxu]

Well, the function should do exactly this thing.

[naderman]

Deciding on a new and improved api for events:

$vars = array('page_title');
$event = 'core.index';
extract($phpbb_dispatcher->dispatch($event, compact($vars), $vars));

Is the reason 'core.index' is stored in a variable, solely so the word event is mentioned? My proposal:

Code: Select all

$vars = array('page_title');
extract($phpbb_dispatcher->trigger_event('core.index', compact($vars), $vars));

This also keeps "dispatch" working the same as in Symfony, but we use trigger_event in phpBB which has the phpBB event semantics?