Types de nœuds, nodes-sources et nœuds

Cette partie est la partie la plus importante de Roadiz. Presque tous les contenus de votre site seront créés sous la forme d’un nœud.

Regardons ce simple schéma de nœud avant de l’expliquer.

Maintenant, il est temps d’expliquer comment ça marche !

Qu’est-ce qu’un type de nœud

Un type de nœud est le gabarit de votre node-source. Il contiendra tous les champs que Roadiz utilisera pour générer une classe de node-source étendue.

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.

Voici un schéma pour comprendre comment les types de noeuds peuvent définir des champs personnalisés dans les 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.

Jetons maintenant un œil sur les sources de nœud.

Sources de nœuds et traductions

Une fois votre type de nœud créé, sa définition est stockée dans la base de données dans les tables node_types et node_type_fields. Ces informations ne seront utilisées que pour construire vos formulaires d’édition de node-sources dans le back-office et pour construire une table de base de données personnalisée.

Héritage des données

Avec Roadiz, chaque donnée basée sur un type de nœud (appelée node-sources) est stockée dans une table différente préfixée par ns_. Lorsque vous créez un type de nœud Page avec 2 champs (content et excerpt), Roadiz dit à Doctrine de construire une table ns_page avec 2 colonnes et une clé primaire héritée de la table nodes_sources. Cela s’appelle : Inheritance mapping, votre table ns_page hérite de la table nodes_sources et lorsque vous interrogez une Page depuis la base de données, Doctrine combine les données provenant de ces 2 tables pour créer une source de nœud complète.

À la fin, votre node-source Page ne contiendra pas que 2 champs, mais bien plus, puisque l’entité NodesSources définit les title, metaTitle, metaDescription, metaKeywords et d’autres champs de données génériques qui peuvent être utilisés sur tous les types de nœuds.

Traductions

L’héritage des données des Node-sources est non seulement utilisé pour personnaliser les données, mais aussi pour les traduire. Comme vous l’avez vu dans la première image, chaque nœud peut possèder de nombreuses sources, à savoir une par langue.