You will learn how to Build an exrm release for NectarCommerce and a quick heads-up on roadblocks and their solutions. It will help you do a dry run in development and production environment on local for less surprises when deployed for use. Continue reading
In the past few posts we have learned how to write code that extends existing models, routers, added methods to override view rendering and run multiple phoenix application together in the same umbrella project. Let’s Continue to build upon that and write our first extension for NectarCommerce favorite products and ultimately our store based on NectarCommerce.
For our curious readers, we tried another extension approach which had linear dependency (nectar => extensions_manager => extensions) helpful in development but turned out to had the serious limitation of Nectar being unavailable for testing.
To overcome the barrier of testing and pleasant developer workflow, what we need is that Nectar is available and compiled while developing extensions and if an extension is added it should recompile itself to include the new extensions.
We have modified Nectar for this approach to seek for extensions and used a custom compiler step(A story for another time) to mark files for recompilation. Let’s get started and see if we can scale the testing barrier.
It’s a walk-through of Extension Approach which has simple, linear dependency (nectar => extensions_manager => extensions) between Nectar, Extensions and Extension Manager and developing an extension is also quite straightforward but turned out to have the serious limitation of Nectar being unavailable for testing. Continue reading
This post aims at documenting how the approach we took to make NectarCommerce extensible is structured, the order of dependencies amongst the various nuts and bolts of NectarCommerce and its extensions as implemented.
NectarCommerce can be divided in two components, both of which reside in the same umbrella application.
As NectarCommerce extensions are envisioned to be used with Nectar and would be dependent on Nectar directly or indirectly, we chose umbrella project to have Nectar, extensions_manager, user_app, and extensions apps as part of it.
We plan to use
phoenix app for extensions where web-component is needed and which would be part of the umbrella project.
We want to allow Extensions to provide alternate view for an existing view in Nectar or provide an alternate template path for all views without changing the Nectar Views.
Alternate View Templates Path than Default for all templates override
We want to allow Extensions to add routes into Nectar Router without modifying the Nectar Router source.
Let’s begin the journey of incremental changes to bring consumer, service and library code into existence starting from a simple use-case of adding a route for showing favorites.
We want to allow Extensions to add support functions to existing Nectar Models without changing the Nectar Models.
Let’s begin the journey of incremental changes to bring consumer, service and library code into existence starting from a simple use-case of adding a function, say
fn_from_outside, to Nectar Product.
We want to allow Extensions to modify the schema of existing Nectar Models without changing the Nectar Models.
Extensions should be able to add new fields and associations to existing models as and when needed.
Let’s begin the journey of incremental changes to bring consumer, service and library code into existence starting from a simple use-case of adding a virtual boolean field, say special, to Nectar Product.
It lists Metaprogramming resources and constructs used in upcoming blogs when creating different extension DSL’s.
Why another tutorial on an already well-documented metaprogramming topic ?
To revise and refresh something that we would refer time and again when reviewing Model, Router, View extension DSLs
Extension DSLs will be using below meta-programming constructs to get the job done :)