Node-types, nodes-sources and nodes

This part is the most important part of Roadiz. Quite everything in your website will be a node.

Let’s check this simple node schema before explain it.

Now, it’s time to explain how it’s working!

What is a Node-type

A node-type is the blueprint for your node-source. It will contain all fields that Roadiz will use to generate an extended node-source class.

For example, a node-type “Page” will contain “content” and “header image” fields. The “title” field is always available as it is hard-coded in NodesSources class. After saving your node-type, Roadiz generates a NSPage class which extends the NodesSources class. You will find it in the src/GeneratedEntity/ folder. Then Roadiz calls Doctrine update tool to migrate your database schema. Do not modify the generated class. You’ll have to update it by the backend interface.

Here is a schema to understand how node-types can define custom fields into node-sources:

All node-types management will be done by editing app/config/node_types/*.yaml files. You will be able to create, update node-types objects and each of their node-type fields independently. Some CLI commands are available to export, list and validate types and fields. We really encourage you to check the commands with --help argument, as following:

nodetypes:default-values  Get all default values for a field across all node-types.
nodetypes:export-files    Migrate database node-types to YAML files.
nodetypes:list            List available node-types or fields for a given node-type name
nodetypes:validate-files  Import all node-type YAML files and validate them.

Keep in mind that each new node-type or adding/removing node-type fields operation will require a database migration. Doctrine has to create specific columns per node-type and fields. Do not forget to execute bin/console app:migrate command to generate a new Doctrine migration based on your changes. It’s very important to understand that Doctrine needs to see your node-types generated classes before upgrading database schema. If they don’t exist, it won’t able to create your custom types tables, or worst, it could delete existing data since Doctrine won’t recognize specific tables. You can execute bin/console generate:nsentities to regenerate your node-types PHP classes.

Now let’s have a look on node-sources.

Node-sources and translations

Once your node-type created, its definition is stored in database in node_types and node_type_fields tables. This informations will be only used to build your node-sources edition forms in backoffice and to build a custom database table.

Inheritance mapping

With Roadiz, each node-types data (called node-sources) is stored in a different table prefixed with ns_. When you create a Page node-type with 2 fields (content and excerpt), Roadiz tells Doctrine to build a ns_page table with 2 columns and one primary key column inherited from nodes_sources table. It’s called inheritance mapping: your ns_page table extends nodes_sources table and when you are querying a Page from database, Doctrine mix the data coming from these 2 tables to create a complete node-source.

At the end your node-source Page won’t contain only 2 fields but many more as NodesSources entity offers title, metaTitle, metaDescription, metaKeywords and others useful data-fields which can be used among all node-types.

Translations

Node-sources inheritance mapping is not only used to customize data but to make data translations available. As you saw in the first picture, each nodes can handle many node-sources, one per translation.