Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ECOMMERCE] Migrate to symfony configuration #1783

Merged
merged 108 commits into from Aug 2, 2017
Merged

Conversation

maff
Copy link
Contributor

@maff maff commented Aug 1, 2017

Resolves #1646

  • Migrate E-Commerce Framework configuration to a Symfony Config tree exposed by the bundle
  • Refactor components to be wired together via DI instead of relying on the Factory and instead of parsing/handling config inside each component

General concepts:

  • Components are not aware of configurations or tenants anymore. The bundle extension/configuration takes care of handling config and transforming the config to service definitions. Examples:
    • instead of calling Factory::getInstance()->getVoucherService() somewhere inside the OrderManager, the order manager requests an IVoucherService constructor argument
    • instead of building payment providers from a config instance, the PaymentManager just gets a set of providers it can access by name

This removes configuration/dependency resolving logic from each component to the extension/configuration, which makes the components itself more predictable, thus easing debugging and testability.

Configuration for components supporting tenants is not split into a general and a tenants section anymore, but defines everything inside a tenants section, defaulting to a default tenant. Inside the config, inheritance can be achieved by defining a special _defaults tenant which is merged into every defined tenant.

maff added 30 commits July 28, 2017 15:02
…c tracker interface as they are enhanced ecommerce specific
…ilder() method from Tracker interface

Constructor will differ by implementation, tracking item builder does
not need to be accessed from outside.
…able via options and simplify template rendering
…nt of config, just accept a list of tracker instances
… (in-memory) and a SessionEnvironment and load session data lazily

Does not load session data upon construction, but on first access.
…fig tree

The config tree expects at least a "default" tenant entry. To define
default values which are used in every tenant, a special _defaults
tenant entry can be used which will be merged into every tenant at
normalization.
…ndent of config

Carts and price calculators are built by factories which are kept as
dependency by the cart manager. The cart manager itself is tenant
specific.
…cart and price calculator factories per tenant

Factory::getCartManager() will return the cart manager matching the
current environment.
…ined via config + container

Simple options are handled via OptionsResolver, environment and voucher
services are injected as dependencies. Agent is now built through a
dedicated agent factory which is added as dependency.
… order manager, cart manager and voucher service toghether via container
…c token managers from Factory to a dedicated TokenManagerFactory
…on tree with support for tenants and placeholders
…s and make default implementation valid

Default implementation did not return an availability, but the concrete
product instead. Now a simple availability value object is returned.

AttributeAvailabilitySystem was renamed to AvailabilitySystem as it does
not handle any attributes.
…for price and availability systems and register them on factory

Ecommerce framework does not handle any options for price and
availability systems. Instead the config expects service IDs which are
wired into the factory through a Symfony service locator containing only
the configured price/availability systems indexed by name.
Christian Fasching and others added 6 commits July 31, 2017 17:58
…nager being bound to the same tenant

Services relying on each other are resolved from the factory at runtime
instead of being injected statically. This makes instances less
predictable but restores existing behaviour and allows to handle
different tenants for different components.
…olve depenent services through service locators

Instead of injecting the factory as done in the previous commit, inject
a component specific service locator (e.g. IOrderManagerLocator) which
can resolve the order manager from the environment when requested.
@maff maff added this to the 5.0.0 milestone Aug 1, 2017
@maff maff self-assigned this Aug 1, 2017
@maff maff changed the title [ECOMMERCE] Migrate to symfony configuration WIP: [ECOMMERCE] Migrate to symfony configuration Aug 1, 2017
@maff maff changed the title WIP: [ECOMMERCE] Migrate to symfony configuration [ECOMMERCE] Migrate to symfony configuration Aug 2, 2017
@maff maff merged commit be2cea0 into master Aug 2, 2017
@maff maff deleted the ecommerce-symfony-config branch August 3, 2017 08:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant