Våra sajter
www.litium.se

Ta ditt hjärta och din själ till webben! Läs mer om webblösningar.
Litium Studio Knowledgecenter

Knowledge Center för Litium Studio
Litium Scensum Knowledge Center

Knowledge Center för Litium Scensum
Litium Partner

Återfinns information som partner till Litium.
Support

Plugin architecture

Introduction

ECommerce plugins allow extending the ECommerce functionality and customizing its behaviour. There are two basic design concepts behind ECommerce plugins.

  1. Seperation Of Concerns: Keep your business logic seperate from User Interface logic
  2. Inversion Of Control: Let implementation take the decisions, on matters best known to implementation.

Seperation Of Concerns

When a project is implemented using Litium Studio, normally you would seperate out the business logic implementation into the code behind files of your website templates, or a set of code files in your app_code directory.

Though this is desirable in most other modules, ECommerce needs a step further. Your custom implementation need to be used by the ECommerce administration as well. For example, you have two ways of placing a order.

  1. From the public website you create
  2. From Ecommerce administration, going to orders view and creating the order.

In both above cases, you will be doing order total calculations, and this calculation is depending on your own implementation. Therefore, the logic you provide in that implementation has to be accessible to both administration as well as to the templates you are writing. To do this, you have to place all your logic into the ECommerce plugins where applicable, so that they are available for administration as well.

Below diagram shows, that how both your templates and ECommerce administration use the logic you provide in the plugins.

 

For an expanded view of how a plugin is implemented, please refer to the diagram in Pricing Rules Plugin. It shows how pricing rule plugin is implemented and how it relates to interfaces inside the Litium Studio API.


Inversion Of Control:

Some of the detailed customizations you would want to have in your implementation project cannot be generalized.
For example,

  1. You would have a campaign which is behaving different in one project implementation to another.
  2. Different implementations may use different payment providers, delivery providers and pricing rules.
  3. You would have different order states in different projects, and different state transitions, and different actions that need to be taken in those transitions.

Therefore, implementation project will need the control of telling the Litium Studio API, how a particular functionality should be implemented. This is done using the IOC design pattern. Effectively, the plugins dynamically defines the behaviour of ECommerce API.

 

In abstract, a class loader called PluginFactory reads the Litium.Studio.Plugins.config file from your web\bin directory, and loads the plugin instances "on demand". That is, they are not pre-loaded, they only get loaded when the first call to the plugin comes.
This feature makes it possible to completely replace the default implementation provided for the plugins to be replaced by your own implementation, by just changing the configuration file.

Extending Vs Replacing Default Plugins

As a designer, you would have two design options regarding default plugins provided as off-the-shelf add-ons. You can,

  1. Replace them with your own ones
  2. Extend them with your own code
  3. Change code directly in them : This is strongly NOT recomended, though it is an option!. (Why? when we upgrade plugins to have fixes and improvements, you will have a pretty hard time dealing with changes!)

Replace from your own code

Just make sure that your plugin implementation is using the correct interface as the default implementation.
Then replace the entry in the Litium.Studio.Plugins.config file. This method would be ideal if your implementation is drastically different from the default implementation provided.

Extend with your own code

Write your classes by extending the classes provided by the default implementation. Usually the default implementation provide virtual methods to allow this type of extention.
Then replace the entry in the Litium.Studio.Plugins.config file supplying your subclass, so that the PluginFactory creates your class instead of the default class.
Effectively this is the "Template Method" design pattern.