EVENTS IN DER PRAXIS - how to make use of events in OXID eShop
Talk was given at the OXID eSales Partner's Day 2019 in Freiburg. Topic is how to make use of the events introduced in OXID eShop 6.2 for shop modules.
(almost) everything > we can break (almost) everything > sometimes we only notice it is broken when other modules are around > some classes we cannot extend (non-leaf classes like the BaseModel for example) IT WORKS but there‘s room for improvement
proxy (Varnish) from EE shop code into module > Write a module using NGINX as reverse proxy > No BC breaks please as it should to go minor AS PO I WANT TO ... So let‘s just move the reverse proxy into a module
`Internal` namespace is to have a clearly defined public API. One of the means to achieve this is the usage of the Symfony DI container to manage services in the `Internal` namespace. The implementations themselves are shielded by interfaces, so the interfaces in the Internal namespace might be considered as part of the public API of the OXID eShop. IT‘S ABOUT TIME ANYWAY Start building a clearly defined public API shop shop module event event
way to enhance shop functionality than the traditional way of enhancing classes. > Register an event subscriber that may react on the event instead of getting inside the class chain. > The events should stay the same over a much longer period of time than code. > Make modules future proof, use events whenever possible. > The framework used for this is the Symfony event handling mechanism. EVENTS The Pros
to subscribe to 2. Write the event subscriber 3. Register the event subscriber in the DI container SUBSCRIBE MODULE TO EVENTS Three steps, that‘s all 1..2..3..
Choose the event(s) to subscribe to > I want to log every time some shop model did change (insert, update, delete). > Subscribe to following DatabaseEvents: ▪ AfterModelDeleteEvent ▪ AfterModelInsertEvent ▪ AfterModelUpdateEvent NOTE: The oxNew way would require us to chain extend each shop model class because we cannot extend the BaseModel in a module.
MODULE Sneak Peek Two parts: > Decide which output to cache or not to cache ▪ Subscribe to ShopGeneralEvents and ViewRenderedEvent. ▪ At the right moment manipulate headers to signal NGINX how to handle response. > (Partially) invalidate the cache on changes ▪ Subscribe to DatabaseEvents and some of the ModuleEvents. ▪ Check the event’s payload and decide if cache needs to be invalidated.
about available events and the example how to use them in the OXID eShop Developer Documentation for OXD eShop 6.2 in section Module resources/Events. GETTING HELP Available Documentation