Comprendre le stockage des données avec SEBLOD

Bonjour

Parmi les nombreuses questions qu'on nous pose en formation sur le CCK Seblod il y en a une qui revient toujours et qui concerne le stockage en base de données.

En effet une des grandes forces de Seblod est de ne pas se contenter de proposer des "super" articles avec des champs personnalisés, ni même de faire des listes et filtres de recherche, ce qui est une fonction déjà tout à fait exceptionnelle mais il s'agit de maîtriser et exploiter la façon dont chaque champ est stocké en base de données.

Cette maîtrise permet de réaliser par la suite des moteurs de recherche et des affichages dynamiques sur des contenus liés jusqu'alors impossibles.

Cela permet aussi d'utiliser Seblod comme une véritable boite à outils de développement rapide en étendant des composants déjà réalisés. Ainsi il devient possible de faire des moteurs de recherche ou des listes dynamiques sur des contenus d'un blog ou d'un forum ou n'importe quel autre composant à partir du moment où on sait créer des champs seblod qui vont "mapper" des champs des composants installés.

Le principe de base absolument essentiel est qu'un type de contenu SEBLOD est un "super" article qui utilise la table #__content comme tout article (on pourra dans un autre billet parler des "super" utilisateurs qui étendent la table #__user) et éventuellement d'autres tables pour stocker les champs supplémentaires.

La liaison devient transparente à partir du moment où on n'oublie pas de:

• mettre le plugin systeme SEBLOD en premier
• mettre le plugin content SEBLOD en premier

A partir de cet instant Seblod prend le pas sur Joomla! et remplace le composant com_content par com_cck en mimant le comportement de Joomla!

Plus exactement Seblod a découpé tout Joomla en petites pièces de puzzle qui sont les champs! Là où l'élement minimal de Joomla était un article monolithique, Seblod rend Joomla plus élémentaire en permettant de travailler au niveau des champs.

Ainsi un article Joomla! devient un type de contenu Seblod mais au final c'est la même chose car ce contenu seblod utilise les mêmes champs dans la base de données.

La différence importante est que Seblod va utiliser le champ introtext de la table #__content d'un article pour stocker les infos qui lui permettent de faire la jointure avec les tables additionnelles des champs ajoutés. C'est précisément parce que les plugins systeme et contenu SEBLOD sont activés et placés en premier que Seblod peut faire le tri, masquer les infos de liaisons ajoutées dans l'introtext à l'utlisateur et lui présenter un affichage avec les champs standards et les champs additionnels.

 Reste à comprendre où sont stockés ces champs additionnels. Il y a en fait 3 scénarios qui dépendent de l'état du "cadenas seblod". Il s'agit d'une simple icône sur les formulaires de création des types de contenu dont l'état (fermé ou ouvert) détermine le stockage des champs qu'on crée ensuite.

Par défaut le cadenas est fermé et les champs standards joomla et leurs alias sont stockés dans #__content. Les champs additionnels sont rangés dans la table#__cck_store_form_

Dans ce cas les champs additionnels ne sont visibles dans la colonne de droite seblod (édition d'un type de contenu ou d'une liste) que pour le type de contenu associé. En fait cette colonne de droite affiche :

• tous les champs qui sont soit des champs standards joomla (ou leurs alias)
• tous les champs spécifiques au type de contenu courant
• tous les champs en cadenas ouvert

Si on veut partager des champs entre différents types de contenu on peut donc:

• soit ouvrir le cadenas avant la création de ce champ
• s'assurer que le nouveau champ, même en cadenas fermé, soit stocké dans un champ de la table #__content de Joomla

Si on veut partager un champ entre plusieurs types de contenus on doit.... dévérouiller le cadenas!

Attention: par défaut un champ créé en cadenas ouvert est stocké en introtext (personnalisé/ article / introtext) ce qui n'est pas idéal quand on veut faire un update du champ ou une recherche (plus longue). Dans ce cas on aura soin de mettre le stockage de ce champs en standard / article. Il sera alors stocké dans la table #__cck_store_item_content

Si maintenant on veut tout de même stocker un champ dans l'introtext il faut préciser le stockage personnalisé / article / introtext[introtext] dans la section inférieur de l'éditeur du champ en question:

Il y a beaucoup d'autres subtilités à comprendre pour aller plus loin mais ces quelques précisions sont souvent le point de départ pour une utilisation vraiment efficace de ce CCK qui permet enfin de libérer la puissance de Joomla!