Extending the LiteCommerce functionality

Module Developer's Tutorial - Extending the LiteCommerce functionality

Extending LiteCommerce classes

First of all, LiteCommerce is a web application written in object PHP 5.3. So, in order to extend its behavior you are to create a module that inherits LiteCommerce classes and their methods as per your needs.

That looks good until you realize that your modification should be transparently applied to other LiteCommerce classes and modules. For example, you are working on a module that reduces all product prices by 50%. So, you extend the product class, override the method returning the product price and... nothing happens. The reason is that neither LiteCommerce nor other modules know about your custom class.

In order to solve this situation LiteCommerce offers a thing called "dynamic decoration".

Let's go back to the above example with extending the product class. In LiteCommerce there is a base class:

namespace XLite\Model;

class Product
{
    ...
    public function getPrice() {
        return $this->price;
    }
    ...
}

In our module we extend the class and override the method:

namespace XLite\Module\<YourCompany>\<YourModule>\Model;

class Product extends \XLite\Model\Product
{
    public function getPrice() {
        return parent::getPrice() / 2;
    }
}

Now, in order to inform LiteCommerce that this class is to be "dynamically decorated" we modify it as follows:

namespace XLite\Module\<YourCompany>\<YourModule>\Model;

class Product extends \XLite\Model\Product implements \XLite\Base\IDecorator
{
    public function getPrice() {
        return parent::getPrice() / 2;
    }
}

After rebuilding the LiteCommerce classes cache, the inheritance chain will look as follows:

1. XLite\Model\ProductAbstract (this is the base product class but automatically renamed by LiteCommerce)
2. XLite\Module<YourCompany><YourModule>\Model\Product extends XLite\Model\ProductAbstract
3. XLite\Model\Product (an auto-generated class with empty body) extends XLite\Module<YourCompany><YourModule>\Model\Product

Now anyone working with XLite\Model\Product will actuall work with your custom implementation of that class without even knowing that.

The same happends when there are multiple modules extending and "decorating" the same base class, but the inheritance chain will be a little bit longer: ProductAbstract -> Product (from module 1) -> Product (from module 2) -> Product (the final one with a blank body)

Since the v1.0.22 there is the ability to specify which modules are required to let a module class be included into the classes cache. For example, we develop a module that adds some custom functions into the core but also may extend two other modules when they are enabled in the shop. To do so in our module we declare our class as follows:

/**
 * A class "decorating" another one only when "Module1" by "Developer1" and "Module 2"
 * by "Developer2" are enabled in the shop.
 *
 * @since 1.0.22
 *
 * @LC_Dependencies ("Developer1\Module1", "Developer2\Module2")
 */
class Test extends \XLite\Module\Developer1\Module1\Model\Test implements \XLite\Base\IDecorator
{
    // ... doing something ...
}