XDDD under the hood part 2 - rendering
To build solutions in data, you need a way of turning data into a running system.
In part 1 of this series we covered how extensible data-driven development (XDDD) is based on a flexible and secure node store, which holds data, data definitions, permissions and users.
To start turning this into a system, we use the definitions to provide a display of the data, a process we call rendering. Because Metrici is a web application, the data is rendered into HTML.
Multiple views of the data are required: pages to view data, web forms to create and update data, and forms to delete data. User input is validated and interpreted based on data definitions. Users can only access data as defined by permissions. In this way, the web application provides complete and secure create, read, update and delete (CRUD) functionality for any data.
As well as rendering the pages into HTML, the user needs to navigate the solution. The web application maps incoming URLs to node references. For example, our home page at https://www.metrici.com/metrici/content is mapped to the node reference "metrici.content". The web application uses the referenced node to respond to the web request.
The underlying data model uses node types to define what data is stored in which fields. To provide a better user experience, the node types and fields include properties that finesse the display, for example to indicate whether a text value can contain multiple lines.
The solution handles files by representing each file as a node. The file upload process intercepts and stores incoming files and passes on metadata (file storage location, file name, file size) which is then stored as node data. When a file nodes is accessed, the web application returns the stored file, not the node data.
Users expect a rich browser experience, with widgets like date selectors, theming and branding. The web application reads themes from data and uses this to merge suitable CSS and JavaScript into pages as they are rendered. We use the principle of progressive enhancement. For example, for date fields we use display properties to add HTML classes which trigger date selector widgets which replace the normal edit of those fields.
Systems do not run in isolation and need to be integrated with other systems. The web application is split from back-end data and processing using a service layer. This is exposed as a secure web service, meaning that anything that can be done in the web application can be run from other systems. There are also services for outgoing calls to other systems, providing effective two-way integration.
The Metrici web application has evolved from simple page rendering and updates to a rich web platform. All of the functionality is defined in data, including node types, fields, properties and themes. Because of this, all development (which is just data maintenance) is carried out within the application itself.
Next week I will cover how we add scripting to data to further enhance solutions.