Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.The store resolver is a service that determines the current store. It fires an event, sees if anything came back, if not, returns the default store.
This allows modules to select the store based on the session, url, user's country, or whatever else crosses their mind.
Comments
Comment #1
bojanz CreditAttribution: bojanz commentedComment #2
bojanz CreditAttribution: bojanz commentedComment #3
vasikeComment #4
bojanz CreditAttribution: bojanz commentedSo, we need:
1) a commerce_store.services.yml file that declares a "commerce_store.resolver" service which accepts an @event.dispatcher
2) The actual \Drupal\commerce_store\StoreResolver class which accepts an event dispatcher in the __construct().
3) A \Drupal\commerce_store\StoreEvents final class (use \Drupal\Core\Render\RenderEvents as an example) with the RESOLVE = 'commerce.store.resolve' constant.
5) A custom ResolveEvent class (use PageDisplayVariantSelectionEvent as an example) which takes a store entity in the constructor and has a setStore() method.
4) The StoreResolver needs a resolve() method which will fire the RESOLVE event and pass it the ResolveEvent class.
Comment #5
stijndmd CreditAttribution: stijndmd commentedPR - https://github.com/commerceguys/commerce/pull/181
Comment #6
stijndmd CreditAttribution: stijndmd commentedComment #7
bojanz CreditAttribution: bojanz commentedThank you for your work, stijndmd!
I'm sorry it took me so long to review this, to be honest we were unsure about the architecture.
At DrupalCon we decided to go another way, and standardize all of our resolving (at that moment implemented in events, plugins and tagged services) on tagged services alone.
So I've used your patch as an example to create the NumberFormatEvent, and rewrote the store resolvers to use tagged services.