The CoreKraft model creates its output (Response) in a way that fits the requirements of the client-side framework it's intended for. This is achieved by following a structured pattern defined in something called a 'NodesDefinition'.

Think of the NodesDefinition as a set of instructions in a simple JSON file. These instructions are organized like a tree with different sections called 'Nodes'. Each Node can provide different types of information like 'Data', 'Views', and 'Lookups' (either individually or a combination). Nodes can also be set up to execute external code stored in a '.dll' file referred to as a 'CustomPlugin'.

The concept of CustomPlugins and how they're used will be explained in a separate article. For now, it's important to know that each Node can be configured to use a specific data source, which is defined using a property called 'datapluginname'. We support different ways to input data queries, including simple inline statements like SQL or JSON, as well as more complex queries stored in separate files. Using files for queries is beneficial because it allows easy testing and editing in external editors.

Every NodesDefinition has a foundational node called the Root node. The structure of the other nodes is defined within its children. Here's an example of what a NodesDefinition might look like:

Overview of CoreCraft Server Implementation

It's worth mentioning that you can use the entire definition or just a specific starting point (Startup Node). This means that each Node can be configured and utilized as a 'Startup' point. This flexibility allows you to create different views using different parts of the available data. More detailed explanations of this will be provided in another article. Below, I'll describe the fundamental System Plugins that we currently offer.

Data Iterator

This component's purpose is to traverse through the Nodes, starting from the 'Startup' Node and recursively moving through its children. It goes all the way down the chain, initializing and triggering the implementation of registered Data Loaders. The default Data Iterator is provided by the System, but users can create their own versions and use them as alternatives if needed.

Data Loaders

The System comes with default implementations of Data Loaders for working with databases and file storage. We currently support Microsoft SQL Server, SqLite, and JSON (with plans for more in the future). Users can also create their own Data Loaders, register them, and use them to interact with various data sources.

ViewLoader

The System provides a basic HTML ViewLoader by default (support for the razor view engine is planned for future versions). Just like with Data Loaders, users have the flexibility to create their own View Loaders and use them as alternatives if desired.

LookupsLoader

Lookups, which are essentially lists of data used to populate lookup controls in views, are an important concept. BindKraft, the client-side component, offers Dropdown and Multiselect controls for this purpose. Unlike Data, Lookups data is structured as a flat list, not a tree. This data is also cached on the client side for efficiency (more details can be found in the Client-side documentation). Basic LookupLoaders for SQL Server, SQLite, and plain JSON data are provided by the System (with plans for expansion). Just like with other components, users can create their own Lookups Loaders and use them if preferred.

Please note that the above example is just a snippet, and there are more details and aspects to explore within the CoreKraft framework.