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 <nbrac...@bsds.de> 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
> 
> -- 
> | New Stars on the Horizon:      GreenCape  ·  nibralab  ·  laJoom |
> | http://www.bsds.de   ·   BSDS Braczek Software- und DatenSysteme |
> | Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
> ------------------------------------------------------------------
> 
> -- 
> 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/9af851fb-a53b-8a3d-6b0c-f7b8012c98cf%40bsds.de.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/5C39045D-3C58-44F8-ACBD-3E519BA7B869%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to