[RFC|Merged] General Hook Architecture of phpBB3.1
Re: [RFC|Accepted] General Hook Architecture of phpBB3.1
Related discussion: https://gist.github.com/26dc674c0062f128c1ab
Formerly known as Unknown Bliss
No unsolicited PMs please except for quotes.psoTFX wrote: I went with Olympus because as I said to the teams ... "It's been one hell of a hill to climb"
Re: [RFC|Accepted] General Hook Architecture of phpBB3.1
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
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
Re: [RFC|Accepted] General Hook Architecture of phpBB3.1
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.
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.
Re: [RFC|Accepted] General Hook Architecture of phpBB3.1
Deciding on a new and improved api for events:
$vars = array('page_title');
$event = 'core.index';
extract($phpbb_dispatcher->dispatch($event, compact($vars), $vars));
$vars = array('page_title');
$event = 'core.index';
extract($phpbb_dispatcher->dispatch($event, compact($vars), $vars));
Re: [RFC|Accepted] General Hook Architecture of phpBB3.1
What I don't like about this is that it is no longer using the standard EventDispatcher API provided by Symfony.
Re: [RFC|Accepted] General Hook Architecture of phpBB3.1
Just for the record, a common idea for extracting previously compacted variables into globals: https://gist.github.com/2113808
Re: [RFC|Accepted] General Hook Architecture of phpBB3.1
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.igorw wrote:What I don't like about this is that it is no longer using the standard EventDispatcher API provided by Symfony.
Re: [RFC|Accepted] General Hook Architecture of phpBB3.1
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 wrote:Just for the record, a common idea for extracting previously compacted variables into globals: https://gist.github.com/2113808
Re: [RFC|Accepted] General Hook Architecture of phpBB3.1
Well, the function should do exactly this thing.
Re: [RFC|Accepted] General Hook Architecture of phpBB3.1
Is the reason 'core.index' is stored in a variable, solely so the word event is mentioned? My proposal:Oleg wrote:Deciding on a new and improved api for events:
$vars = array('page_title');
$event = 'core.index';
extract($phpbb_dispatcher->dispatch($event, compact($vars), $vars));
Code: Select all
$vars = array('page_title');
extract($phpbb_dispatcher->trigger_event('core.index', compact($vars), $vars));