Oui c'est comme dans le plugin Forms&Tables (mais peut etre que l'interface est "mieux").
On créé des objets virtuels qui ne sont pas mappés en base par une table, mais stockés dans une table à plat
Cela donne des super requêtes comme expliqué ici http://www.spip-blog.net/Drupal-et-mySQL-sont-sur-un.html
(comme dans F&T d'ailleurs )
C'est *THE* feature de Drupal, car elle permet de créer ses objets métiers dans programmation.
On en est plus très loin dans SPIP, mais avec une vrai BDD derrière.
Encore un peu de travail et de reflexion, sûrement ...
C'est *THE* feature de Drupal, car elle permet de créer ses objets métiers dans programmation.
On en est plus très loin dans SPIP, mais avec une vrai BDD derrière.
Encore un peu de travail et de reflexion, sûrement ...
Puis-je me permettre un retour utilisateur à ce sujet ?
Toutes les semaines je maudis cette possibilité Drupalienne, en tant qu'utilisatrice d'un extranet qui permet ainsi 5 objets différents. Le problème c'est qu'une fois que l'on fait le choix d'un objet, on ne peut plus en changer (ou alors notre dev est un abruti). Deux ans après, nous voici avec une tonne de contenus mal typés, donc mal rangés, donc difficiles à trouver, donc peu exploitables, etc.
Je me rassure en me disant qu'on ne pâtit là que d'une erreur de conception initiale...
Et je me dis que si l'on voulait bien faire (dans SPIP), on ferait tout en articles, avec des champs supplémentaires (extra2), que l'on afficherait que ça et là, ce qui permettrait de basculer d'un "type d'objet" à un autre. Bref, en modifiant plus l'interface que la base de données.
Un développeur de mon entourage me dit que ce n'est pas le cas et que dans la majorité des cas Drupal crée bien une table supplémentaire pour chaque nouveau type d'objet, et fait bien des "alter table" quand on modifie un champ.
Un truc cool aussi : tous les nouveaux objets sont automatiquement versionnables.
)