OroPlatform Forums

Covering OroPlatform topics, including community updates and company announcements.

Forums Forums OroPlatform OroPlatform – Feature Requests Extensibility in AOP-style

This topic contains 1 reply, has 2 voices, and was last updated by Michael Michael 4 years, 6 months ago.

Starting from March 1, 2020 the forum has been switched to the read-only mode. Please head to StackOverflow for support.

  • Creator
  • #36809


    There are several ways to extend classes:

    One can use the bundle class inheritance:

    or the service tags:

    The main problem of extensibility by inheritance (like Oroplatform and Magento 1 has it) is that only one third party module can extend another class. If more than one modules tries to overwrite a class, a conflict occurs, which then has to get resolved in source code by making tight dependencies between the affected modules.

    Using service tags (DI or Event/Observer) is a limited possibility to extend the system because there are/will be never enough of the entry points.

    So from my point of view, the best way to get deeper into the system by not messing up the source code is to use techniques a lá Aspect-oriented programming, which has been implemented in Magento2, called “plugins”:

    there is the similar solution on a lower level:

    This approach eliminates the risk of having conflicts at the structural level between multiple bundles.
    (of course there will be still risk of conflicts on the behavioral level, but that’s not the point)

    So my question:
    Are you interested in implementing a similar technique of extensibility like magento 2’s plugins?

    Or, if I’m totally wrong about the possibilities in Symfony and Oroplatform:
    Are there such kind of extension possibilities?

Viewing 1 replies (of 1 total)
  • Author
  • #36810

    Hi Denis,

    Some of the assumption you’ve made in the question are incorrect.

    We do not really use, neither recommend anyone to use extensibility by inheritance.

    The recommended way is to use tags and service decoration in the container.

    If something is not defined as a service, then:

    • you may contribute a pull request that defines the service
    • there are places in the system where due to performace-related or other considerations we do not allow to modify the default behavior. You may still modify the original code, or override it using other means (e.g. autoloading priorities or class aliases) – but we are not going to support such modification
Viewing 1 replies (of 1 total)

The forum ‘OroPlatform – Feature Requests’ is closed to new topics and replies.

You will be redirected to [title]. Would you like to continue?

Yes No