Hi Larry, It'll be a first for me but I'll be glad to be part of the Event Dispatcher working group.
Kind regards Stéphane Le mardi 13 mars 2018 22:58:35 UTC+1, Larry Garfield a écrit : > > Well, I've been talking about stepping forward to take over as PSR-14 > Editor > for a few weeks now. I should probably go ahead and do it since there > seems > to be interest. > > Before we start showing code, I'd prefer to step back and define the > specific > use cases we want to target. Benni's list below is a good starting point > for > that discussion. That would probably be some discussion in Slack or > similar > within the WG first. I would prefer to not use a separate GitHub group > but we > can coordinate that with the secretaries. > > Those who are interested in being part of an event dispatcher PSR-14 > working > group (I suggest we change the name since "manager" is so pointlessly > generic), please ping me by email or Slack. > > We also would then need another CC member to sponsor before we can > formally > open a vote to reactivate the WG. Who's up for it? > > Note: My time will be a bit scarce for the next week as I'm working for a > political campaign, but the election is next Tuesday so win or lose I > should > have more time available at that point. :-) > > --Larry Garfield > > On Tuesday, March 13, 2018 9:26:40 AM CDT Barney Hanlon wrote: > > Is this the right forum for putting forward examples of our own work as > > potential candidates? I’ve been working on one under the name event > interop > > (much as PSR-11 was born from) but it seems we all have similar ideas. > > Shall we start showing some code examples? > > > > > Hey folks, > > > > > > I've been meaning to share my feedback for quite some time on that. > > > > > > We've looked into different implementations a lot and we (TYPO3 dev) > would > > > only consider Event Manager if we're talking about immutable events. > And > > > event is triggered, could have parameters, but the event itself should > not > > > allow to alter parameters. > > > > > > A classic example in our project is to change/modify values before > storing > > > them in a RDMS - this is not an event. Modifying a request object is > not > > > the job of an event listener. Of course, if you hand over objects as > > > parameters, it's hard to enforce that they are kept as they are. > > > Events to modifying parameters is a different pattern, and we should > aim > > > to differentiate between them. > > > > > > Once this is in the mind-set, an event (and event system) is actually > very > > > simple - also ordering is not _as_ important anymore (for our > use-cases). > > > However, it showed that an event system is only half of the business, > and > > > that it should be accompanied by a hooking system. > > > > > > Basically we consider three different use cases: > > > - Events (Immutable) - "Hey, I just persisted something" then we could > > > flush Caches > > > - Filters / Pipelines - "Here is some data, go and enrich it" - then > we > > > could have plugins of a framework modify or add metadata to the > records, > > > based on the current request. > > > - Filters / Interceptors - If one of the "listeners" actually says" > no, > > > you can't do that", the following action should not be called - like a > > > permission system. > > > > > > I'm happy to join the WG to make the PSR-14 as event manager ready, > > > however, I do believe that we should start thinking more. > > > > > > All the best, > > > Benni. > > > > > > On 13. Mar 2018, at 14:38, Niels Braczek <nbra...@bsds.de > <javascript:>> wrote: > > > > > > Am 13.03.2018 um 10:58 schrieb Barney Hanlon: > > > > > > I would recommend that setParam or indeed any setting of properties be > out > > > of the spec. In my opinion, Events and Commands should both be > immutable, > > > but people are open to implement configuration post-construction if > they > > > wish. But if the spec defines these, then the spec is defining the > payload > > > of them as mutable. That doesn’t strike me as a good idea. > > > > > > > > > +1 > > > > > > Regards, > > > Niels > > > > > -- You received this message because you are subscribed to the Google Groups "PHP Framework Interoperability Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+unsubscr...@googlegroups.com. To post to this group, send email to php-fig@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/4cfa16cb-6671-4beb-a8a2-8c1a0492a7c6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
