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.
Par exemple, un type de nœud « page » contiendra les champs « content » et « header image ». Le champ « title » est toujours disponible car il est codé en dur dans la classe NodesSources
. Après avoir sauvegardé votre type de nœud, Roadiz génère une classe PHP NSPage
qui étend la classe NodesSources
. Vous le trouverez dans gen-src/GeneratedNodeSources
(ou app/gen-src/GeneratedNodeSources
avec Roadiz Standard edition). Roadiz appelle alors l’outil de mise à jour Doctrine pour migrer votre schéma de base de données. Ne modifiez pas la classe générée. Vous devrez la mettre à jour par l’interface d’administration.
Voici un schéma pour comprendre comment les types de noeuds peuvent définir des champs personnalisés dans les node-sources:
Le plus gros de la gestion des types de nœud sera effectués dans l’interface du back-office. Vous serez en mesure de créer, de mettre à jour les types de nœud et chacun de leurs champs de manière indépendante. Mais si vous préférez, vous pouvez utiliser les commandes CLI pour créer des types et des champs. Avec les commandes CLI de Roadiz, vous obtenez plusieurs outils pour gérer les types de nœuds. Nous vous encourageons vraiment à vérifier les commandes avec l’argument --help
, comme suit:
bin/console nodetypes:add-fields
bin/console nodetypes:create
bin/console nodetypes:delete
bin/console nodetypes:list
Gardez à l’esprit que chaque opération de type de nœud ou de type de nœud nécessite une mise à jour de la base de données car Doctrine doit créer une table spécifique par type de noeud. N’oubliez pas d’exécuter les outils bin/console doctrine:schema:update
pour effectuer des mises à jour. Il est très important de comprendre que Doctrine a besoin de voir les classes générées par vos types de nœuds avant la mise à jour du schéma de base de données. S’ils n’existent pas, il ne pourra pas créer vos tables de types personnalisés ou pire, il pourrait supprimer des données existantes, car Doctrine ne reconnaîtra pas ces tables spécifiques.
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.