One of our core values driving the development of StoreBuilder is to provide the ultimate in flexibility, customization and extensibility. If you have any experience developing ecommerce websites you'll know how often a platform promises the world, but falls short in some small specific way that is of course pivotal for your project requirements. Or how often a platform says "we support all those features via plugins/add-ons" only to find out later that Plugin A won't work with Add-on B after paying a big consulting fee for Customization C.
StoreBuilder provides a number of mechanisms for extensibility including ViewModel extensibility, Data model eventing, Data Model Custom Properties and a robust plugin architecture.
Most data models in StoreBuilder can be extended with Custom Properties. Custom Properties is how data that is not part of the core StoreBuilder database schema can be persisted. Plugins may add custom properties to store custom data. Your custom code can make use of Custom Properties to store your unique data.
You can expose your custom property within a ViewModel however you like using ViewModel Extenders. This includes the ability to format or transform the custom property data before it is provided to ThemeEngine for rendering of one or more Handlebars templates.
The ViewModel architecture in StoreBuilder allows for Mixins (multiple inheritance) as well as ViewModel Extenders (for data transformations, formatting, etc).
For example the base
ProductViewModel class can be extended by both a ProductReviews plugin and a YouTube plugin. Both plugins will "mixin" additional properties to our
ProductViewModel in order to expose product rating data and youtube videos. Neither plugin is exclusive of the other. And if you want to transform the data provided by either plugin you can add your own custom
ProductViewModel extender to to transform/format any data in the ViewModel including data added by plugins.
This makes it so that not only can the core product be extended, but even proprietary StoreBuilder plugins and add-ons have an open development layer where you can adjust the ViewModel and Handlebars templates to achieve your project objectives.
Data Model Eventing
All data models in StoreBuilder expose events which are triggered when records are inserted, updated, trashed, or deleted in the database. Plugins or your custom code can subscribe to the data events so you can perform some custom action when something happens in StoreBuilder.
- Inserting: Occurs before a model is inserted in the database. Custom code can prevent the insert if an exception is thrown here.
- Inserted: Occurs after a model is inserted in the database. At this point the data is committed within the database.
- Updating: Occurs before a model is updated in the database. Custom code can prevent the update if an exception is thrown here.
- Updated: Occurs after a model is updated in the database. At this point the data is committed within the database.
- Trashing: Occurs before a model is trashed (soft deleted or virtually deleted) within the database. Custom code can prevent this change from being persisted if an exception is thrown here.
- Trashed: Occurs after a model has been trashed in the database. At this point the data is committed within the database.
- Deleting: Occurs before a model is physically deleted from the database. Custom code can prevent the model from being physically deleted if an exception is thrown here.
- Deleted: Occurs after a model has been physically deleted from the database. At this point the change has been committed within the database.
Many plugin will be listening for one of the above DataModel Events and then want to perform some action when that event occurs. If that action is performed inline (within the event handler) it will be blocking to the calling code and could in some case cause calling functions to fail if an unhandled exception were thrown. This capability of executing custom code inline when the event fires should be reserved only for code which is absolutely critical to run as part of business process because you want the ability to stop a process from completing. For example custom security authorization code, custom business validation code, etc.
In most cases, if you are performing some kind of syncronization with a 3rd party system or software, alerting systems/people of activity, sending emails or test messages or other tasks like this, the task should be scheduled to run outside of the triggering event.
This can be done many ways including regular old
ThreadPool.QueueUserWorkItem(), however their is no built in mechanisms for retrying failed tasks or even guaranteeing that they complete or execute at all.
For that reason we have a task management abstraction built into StoreBuilder.
Plugins are a package (.net assembly) which contain some additional functionality for your ecommerce storefront. Built-in plugins may implement 3rd Payment Gateways, Shipping Carriers interfaces, Accounting Software Integration, CRM Integration, etc.
Plugins will often make use of multiple if not all extensibility features listed above in order to achieve their purpose in full. Plugins may contain a new ViewModel class definition, or a class intended to be mixed into a core ViewModel. Plugings may add and maintain Custom Properties. Plugins may subscribe to various platform data events in order to trigger some custom functionality or data synchronization. Plugins may also contains some default handlebars templates which will be copied into your current theme folder to allow for customization.
For more information see Plugin Architecture and Customization.