Je ne m'était pas encore mélé de cette discussion, mais
personnellement, ça me parait très compliquè à mettre en place.
Ajouter un niveau de virtualisation implique de générer
automatiquement du code beaucoup plus complexe, puisqu'il
faudra déterminer dynamiquement le type de chacun des
éléments à manipuler pour savoir comment les
trier/selectionner/mettre à jour... [...]
Bonjour,
Je comprends les réticences (peut-être un tel concept n'est-il pas
compatible avec la philosophie de SPIP ? Je ne sais pas). Néanmoins,
plusieurs arguments plaisent, me semble-t-il, pour qu'on abandonne pas
aussi vite l'idée. Je ne connais pas les systèmes que tu cites (JSP,...
je serais intéressé d'avoir quelques références sur la question) mais
les réflexions postées ces derniers jours sur la liste me paraissent
pertinentes et rencontrent des besoins réels.
Pour résumer le débat, je crois qu'on peut dire que l'avenir de SPIP
est, soit de rester un système dédié au format "webzine" et au seul
format "webzine" (des articles et des brèves classées en rubriques), ce
qui ne correspond qu'aux besoins de certains utilisateurs très typés,
soit de s'ouvrir au traitement de types de données plus nombreux, en les
intégrant bel et bien à l'architecture logique de SPIP (arborescence +
mots-clés). Cette dernière orientation, en rupture avec la philosophie
initiale de SPIP, correspond sans doute aux besoins du plus grand nombre
de nouveaux utilisateurs (dont moi) qui cherchent à se servir de SPIP
pour réaliser un site web dynamique facilement mais pas nécessairement
un webzine.
Si l'on décide de s'orienter dans cette seconde voie, trois solutions me
paraissent exister :
1. On multiplie les types. En plus de "article", de "brève", on
développe alors un type "entrée d'agenda" (un agenda doit intégrer
d'autres données que celles qui sont permises par le bidouillage
d'agenda, sympathique mais bidouillage, disponible sur spip-contrib), un
type "photo" et un autre "galerie de photos", et d'autres selon les
besoins.
2. Deuxième solution, on rajoute une couche d'abstraction. Dans la
manière dont je le conçois, il s'agit de fondre toute les données en
deux table. Une table "contenu" (contenant toutes les données) et une
table "meta" (contenant la typologie de chacune des données et
organisant le lien entre la table "contenu" et son exploitation). Ce
type d'organisation des données se heurte, comme ça a été souligné,
(entre autres) au problème du conflit des types de données dans les
champs de la table (les besoins des différents types ne sont pas
facilement compatibles au sein d'une même table). Un problème
d'optimisation se posera sans doute aussi.
3. Troisième solution : on conçoit un système hybride entre les deux
premiers (ma proposition, trop peu réfléchie qu'elle est). On commence
par identifier les types particuliers (ou fondamentaux) dont on a
besoin. A mon sens, en voici la liste (hors des types meta comme
"rubrique" ou "mot-clé") :
- article (ok)
- brève (ok)
- lien (je sais pas)
- entrée d'agenda (inexistant)
- photo (ce qui existe déjà avec img, mais en rajoutant quelques
champs et en créant une interface dédiée)
- galerie de photo (qui peut être fusionné avec "article" ou
"rubrique" sans trop de difficulté). Il s'agit seulement de permettre le
regroupement des photos.
Ensuite, on crée une typologie "abstractive", mais sur le seul type
"article", en enrichissant celui-ci des quelques champs qui pourraient
lui manquer (la possibilité de créer un cadre de texte). C'est alors
plus léger : l'abstractivité se résume à l'inclusion ou non de chaque
champ potentiel dans le type et on ne va pas plus loin.
Sur le fond, on devrait pouvoir enrichir la réflexion de façon
extraordinaire en allant lire les propos des structuralistes ou de
linguistes comme Chomsky. J'ai la conviction (sans les connaître
autrement que par quelques cours superciels) qu'en creusant, on pourrait
y trouver une solution vraiment "géniale" pour la conception d'un
système d'organisation des données à vocation plus universelle.
en espérant que ceci intéressera l'un ou l'autre,
François