Table of Contents
|MMOD DOCUMENTATION WIKI (node-kit SERIES)|
|The History of NK|
|How to Build a Kwaeri Application|
In this Article
- The Historical Introduction
- The Synopsis
- The Problem
- The Solution
- The Evolution
The Historical Introduction
This article covers the history of nodakwaeri, including how the nk Framework came to be - in detail - as well as how node-kit was evolved.
If you're looking for how to get started with using node-kit - please read the documentation HERE.
nodakwaeri was designed to be a CMS application for the Node.js runtime, with a focus on supporting AJAX concepts.
Most CMS applications are designed in such a fashion that they function from a single entry point (an index), and responses are rendered based upon a route and its subsequently discerned action controller's direction. They resemble dynamic single page applications (SPAs) at a higher level, yet they are typically synchronous in operation.
In order for your typical CMS application (like Wordpress, or Joomla!) to function asynchronously, a serious amount of modification to the core of the application must be made.
Leveraging Existing CMS Applications
In our experience, basic plug-ins or middle-ware have been known to exist for several of the more popular CMS applications, which force asynchronous operation globally - however crudely - yet a very limited amount of control is available through such an implementation, mostly due to the lack of support for such operation being present within the CMS itself.
One common method of achieving asynchronous operation within a CMS application is to install an extension, which itself operates as an asynchronous CMS. The extension's counter-parts, typically installed as modules - provide instruction for how to render content on the front-end, become the main container of the application, and serve the client-side application which implements asynchronous operation.
The downside to this implementation is that a majority of the CMS is not utilized, and extensions ultimately end up functioning as overly complex controllers. The benefits which are provided by the CMS application - such as the MVC architecture, organization, and themes, are typically lost to the extensions which implement such functionality.
The CMS becomes nothing more than a mammoth of an application that allows for extensions to be installed, and which provides routing between and to component extension routes. Calls to component routes are typically made asynchronously, and to work properly - require that the CMS deliver raw responses, or responses which lack any routing through the application's other plug-ins, extensions, or even its theme system.
Leveraging Existing MVC Frameworks
Trying to harness the underlying MVC Frameworks leveraged by a CMS application resulted still in challenges, as the inner workings of the MVC Frameworks were designed for synchronous operation. Controllers and View systems still needed to be modified to serve purpose with out being wasteful or redundant - and mechanisms for common challenges observed in asynchronous applications were non-existent.
The solution would be to build a MVC Framework which solved the underlying challenges of asynchronous applications, and more so the challenges in creating a platform that standardized implementation. nodakwaeri supports AJAX concepts from the ground up; it provides a MVC framework, and a hierarchy for organization.
As an aside, it was decided that it would be best to use a technology that might benefit more with yet another platform variety. Thus, Node.js served as an excellent target.
An Overview of nodakwaeri
The most basic implementation of an application leveraging nodakwaeri provides a template for building an application for the Node.js runtime. Such an application requires a developer to provide, at a minimum, controllers and views. Controllers add routes to - and contain logic for - the application, while views provide instruction on how content will be rendered in a response to a request.
The MVC Template
href attributes, and are subsequently handled silently, and asynchronously. Special data-attributes are used to indicate and provide advanced functionality in this regard.
Within a controller, developers have access to a
layout property, which can be used to control how content is prepared by the view system. Shared and partial layouts may be used. Additionally, other properties exist which allow developers to control how content is rendered within the client application when it is received.
As is common, a viewbag is present and accessible within a controller. The
viewbag property is subsequently accessible to the view system. The view system provides a HTML Template Engine that allows the use of special syntax - termed kwaeri markup language - within a view, or a
Kwaeri markup provides instruction to the view system for how to render content. It can be used to template HTML according to some logic. Examples of its usage include:
- Generating a table structure, the data of each row obtained from an array.
- Displaying a Sign in button, or a User menu, based upon the logged-in status of the user.
- Generating form controls by invoking a utility function and providing data from the viewbag.
Various artifacts, such as session data and query parameters, are also accessible to the view system. In this fashion, developers may leverage the tooling available with the controllers and views to build a robust and dynamic application, in a truly innovative way.
As a follow up, models are also available to nodakwaeri applications - and provide a means to incorporate persistent data. Models are typically manipulated within a controller, and provide facilities for seamlessly accessing a database and for manipulating data.
The XRM Template
The nodakwaeri MVC template is the most basic implementation of the nodakwaeri MVC architecture, and is the foundation for the end-game - The XRM Template. The XRM template expands upon its ancestor, and introduces a single, truly powerful facility; The extension system.
The core framework and tooling provided by nodakwaeri were expanded to take into consideration the concept of front-end and back-end applications. Subsequently, the new template introduced the hierarchy of two MVC applications within a single file and folder structure. Finally, an extensions controller and model were added to the hierarchy of both applications to incorporate usage of extensions within either application type, respectively.
Some additional changes were introduced, such as that of module positions to the theme system, and the concept of modules to controllers and the view system. As is typical of a CMS application, this enabled the management of content within the back-end application - as well as the dynamic rendering of such content for the intended audience within the front-end application.
A CMS extension was developed, and is provided with the XRM template for both applications - and may be modified or replaced entirely. The default template was extended with module positions, and additional front-end extensions are provided which extend the system with common modules in order to provide a full and complete application.
A High-Level End-User Overview
Users may log into the back-end application, navigate to the CMS extension, and proceed with adding menus and/or menu-items. Menus are considered a module, and may be assigned to module-positions. By navigating to modules within the back-end application, a user may view their list of modules, select a menu they have added, and assign it to a position - the most applicable being that of the main-menu.
Additionally, users may create articles through the CMS extension. Within the create article interface, users may opt to select that the article be that of type Article or Blog. Back in the menu-item interface of a specific menu, users can select that a menu-item be that of type Page - or of one of other types that the CMS extension enables, such as Blog List or Blog Category.
The front-end menu module, assigned to the menu module position, will dynamically populate the menu with items managed within the back-end application. This takes place when the default route is processed. Subsequent navigation appropriately bypasses this function, as the XRM template is designed - like its predecessor - to incorporate AJAX concepts from the ground up.
When a user selects a menu-item that has been configured to be of type Page, the application's main view will change to that of a page, and be populated accordingly. Options within the create article interface allowed the application owner to decide whether to include modules - updating only the main-content area of the application interface - or to provide a different layout altogether.
Similarly, if a user selects a menu-item for that which has been configured to be of type Blog Category, or Blog List, the application content is updated accordingly.
menu-item-types, can be added by installing additional extensions. The same holds true for modules. Module positions can be expanded upon by installing different themes - or by modifying the default. In such a fashion, the XRM template transforms the nodakwaeri MVC template into a scaling dynamic single page application, designed entirely to function asynchronously from the ground up.
A High-Level Developer Overview
The XRM template allows for developers to extend the application by providing extensions, rather than by adding base controllers, models, or views - though they are still free to do so.
Back-end extensions allow developers to add content management. Front-end extensions allow developers to provide themes, menu-types, menu-item-types, and modules. The correlation is a powerful asset to a developer, and allows for any manner of application to be developed that is easily distributed and utilized by end-users.
Similarly to the MVC template, the XRM is an AJAX application from the ground up. Tooling is expanded to allow for developers to control how content is rendered, how content may effect the front-end layout, and ultimately provides a standard way for developers to impact the experience of an end-user.
As time passed, the Node.js ecosystem evolved - and this created a need for the nk MVC Framework to evolve as well. With the introduction of technologies such as Typescript, and supporting software such as Babel, Gulp, Webpack - there existed a variety of enhancements that could be made. Thus the @kwaeri scope was born.
@kwaeri/node-kit does not directly evolve the XRM Template. Instead, node-kit claims nk as its core, and evolves the MVC Framework.
node-kit evolves the nk MVC framework by decoupling its many components into self-contained component packages under the @kwaeri scope. Additional end-to-end tooling is also provided with the node-kit module, which subsequently serves as the framework's entry point.
This enforces a modular construction to the hierarchy of the framework, allows for the framework to be installed as part of a platform, and empowers developers with a modern tooling for developing applications for Node.js - which is the modern practice for platform development.
@kwaeri/node-kit - and nk - will no longer serve as a framework for developing an AJAX CMS, but instead serve as a platform - and its core, respectively - for application development with Node.js.
Continued development of node-kit will serve to enhance the platform and to continuously keep it up to date by ensuring that it provides expected functionality as compared with modern technologies, best practices, as similar alternatives.
To get started with node-kit, visit Getting Started with node-kit