Un carnet plus moderne

Alors, quoi de neuf ?

Pour moi carnettiste, de nombreuses commodités d'administration avec une interface plus agréable et surtout avec moins de modules à gérer (de 19 à 13 modules, avec un niveau de fonctionnalités supérieur). Et aussi le plaisir intellectuel d'avoir son outil à jour.
Pour vous lecteurs, de nouveaux styles pour les écrans, les mobiles et l'impression, une catégorisation des billets avec des filtres, un éditeur de commentaires plus agréable... et surtout plein d’améliorations qui ont été rendues possibles par cette mise à jour et qui vont arriver les prochaines semaines !

Un défi technique

L'architecture de Drupal 6 comportaient de nombreuses limitations qui ne pouvaient être contournées qu'avec des hacks, des bricolages pas toujours heureux. Le déséquilibre entre les nodes, qui bénéficiaient de tous les avantages de Drupal (CCK, vues, i18n...), et les autres constituant du CMS était la plus gênante de ces limitations.

Comme beaucoup d'utilisateurs de ce CMS, j'avais donc délaissé les commentaires, les utilisateurs et les taxonomies pour tout baser sur les nodes (avec une utilisation intensive de node_reference). Maintenant que ce déséquilibre a été gommé par l'introduction des entités, il m'a fallu redécouvrir et me réapproprier ces aspects de Drupal, et donc ré-architecturer le site et la base de données avec tout le travail que ça implique.

(Note personnelle en prévision de la future migration vers Drupal 8 : ne surtout pas s'emballer sur les entités et répéter les erreurs faîtes avec les nodes ! Entities are the new nodes.)

Oooooh ! Un triplestore !

D'ailleurs, je suis un grand fan de la nouvelle architecture de données de Drupal basée sur la Field API. Bien sûr, c'est encore nouveau, incomplet et pas très propre, mais c'est prometteur car j'y vois la solution tant attendue aux problèmes induits par l'utilisation des bases de données relationnelles. En effet, celles-ci sont incapables de répondre nativement à des problématiques désormais très courantes comme notamment la gestion des valeurs multiples et le multilinguisme.

Mais comme les bases de données plus modernes (basées sur les documents comme MongoDB, sur XML comme eXist, ou sur RDF comme Sesame) tardent à s'imposer, l'utilisation des ORM est devenue obligatoire. Cependant, ce ne sont que des caches-misères, car derrière leurs belles interfaces orientées-objets ils usent et abusent des tables de jointures, rendant la structure des tables peu claire.

Par exemple, pour ces objets :

city/1 :
	name : "Londres"@fr
	name : "london"@en
	inhabitants : "7,825,200"
	twins: [city/2, city/3]

city/2 :
	name : "Berlin"
	inhabitants : "3,450,889"

city/3 :
	name : "Moscou"@fr
	name : "Moscow"@en
	inhabitants : "11,514,300"

Avec un ORM comme Doctrine, nous avons grossièrement les tables suivantes :

INSERT INTO `city` (`id`, `inhabitants`) VALUES
(1, '7,825,200'),
(2, '3,450,889'),
(3, '11,514,300');

INSERT INTO `cityname_translation` (`id`, `content`, `lang`) VALUES
(1, 'Londres', 'fr'),
(1, 'London', 'en'),
(2, 'Berlin', 'und'),
(3, 'Moscou', 'fr'),
(3, 'Moscow', 'en');

INSERT INTO `city_twins` (`city_id`, `twin_id`) VALUES
(1, 2),
(1, 3);

Trois tables, trois structure de données.

Cependant, avec Drupal, nous avons plutôt quelque chose comme ça :

INSERT INTO `field_name` (`id`, `lang`, `delta`, `value`) VALUES
(1, 'fr', 0, 'Londres'),
(1, 'en', 0, 'London'),
(2, 'und', 0, 'Berlin'),
(3, 'fr', 0, 'Moscou'),
(3, 'en', 0, 'Moscow');

INSERT INTO `field_twin` (`id`, `lang`, `delta`, `value`) VALUES
(1, 'und', 0, 2),
(1, 'und', 1, 3),

INSERT INTO `field_inhabitants` (`id`, `lang`, `delta`, `value`) VALUES
(1, 'und', 0, '7,825,200'),
(2, 'und', 0, '3,450,889'),
(3, 'und', 0, '11,514,300'),

Certes, avoir une table par champ plutôt qu'une table par classe peut être perturbant au début, mais nous n'avons ici aucune table de jointures et toutes les tables partagent la même structure. Et puis regardez-bien ces colonnes, regardez-les de près, ce sont des triplets explicites ! Oui, oui, nous avons un triplestore !