ssossossosso

Forums

Covering OroCRM topics, including community updates and company announcements.  Subscribe

This topic contains 1 reply, has 2 voices, and was last updated by Michael Michael 5 months, 1 week ago.

  • Creator
    Topic
  • #33535

    Metzler
    Participant

    There are several ways to extend classes:

    One can use the bundle class inheritance:
    http://symfony.com/doc/current/bundles/inheritance.html

    or the service tags:
    http://symfony.com/doc/current/reference/dic_tags.html

    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”:
    http://devdocs.magento.com/guides/v2.1/extension-dev-guide/plugins.html

    there is the similar solution on a lower level:
    https://github.com/AOP-PHP/AOP

    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
    Replies
  • #33547
    Michael
    Michael
    Oro Core

    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)

You must be logged in to reply to this topic.