Comme dit je ne sais où récemment, Le core de SPIP peut presque fonctionner seul (ie sans aucune extensions, c'est à dire sans aucun des plugins qui ont été sortis du core).
Il reste 2 (je crois) plugins qui résistent : mots & dist
Je passe volontairement sur la dist, qui en absence fait des "voir en ligne" => 404
Je m'intéresse dans un premier temps au cas de mots.
Le point noir est la présence dans prive/objets/liste/(articles.html | rubriques.html) de critères optionnels {id_mot ?}
Lorsque le plugin mots n'est pas là, le compilateur râle à juste titre de ne pas connaître de jointures possibles avec id_mot.
Je vois 2 actions possibles :
- enlever {id_mot ?} de ces squelettes, et que le plugin mots surcharge ces boucles, soit en surchargeant le fichier, soit via le pipeline pre_boucle ? . Cela me semble une mauvaise solution car il y a d'autres lieux où le problème peut se poser : par exemple dans un squelette distribué généraliste, qui peut avoir les mêmes critères.
- trouver un mécanisme pour dire : ce critère peut être en erreur (introuvable), mais c'est normal, pas d'affolement. Par exemple en utilisant le caractère @ comme en php : {@id_mot ?} ou un second point d'interrogation {id_mot ??} ...
Quelqu'un a t'il des avis ou des idées là dessus ?
Je passe volontairement sur la dist, qui en absence fait des « voir en ligne » => 404
Il faut aussi vérifier Brèves m’a dit Denis car il semble qu’un id_breve traine quelque part (ça vient de mon oreillette…)
Sinon, je pense qu’il manque juste un public minimal qui soit en relation avec les objets de base.
La dist n’a rien à voir avec ça, c’est peut-être là le leurre.
Je m’intéresse dans un premier temps au cas de mots.
enlever {id_mot ?} de ces squelettes, et que le plugin mots surcharge ces boucles, soit en surchargeant le fichier, soit via le pipeline pre_boucle ? . Cela me semble une mauvaise solution car il y a d’autres lieux où le problème peut se poser : par exemple dans un squelette distribué généraliste, qui peut avoir les mêmes critères.
trouver un mécanisme pour dire : ce critère peut être en erreur (introuvable), mais c’est normal, pas d’affolement. Par exemple en utilisant le caractère @ comme en php : {@id_mot ?} ou un second point d’interrogation {id_mot ??} …
Je suis d’accord avec ton analyse sur la solution 1 mais je trouve que la solution 2 n’est qu’un emplâtre. Donc je pense que ces deux solutions sont aussi mauvaises l’une que l’autre car elles prennent le problème à l’envers.
Finalement, ma conclusion serait que le seul objet à ne pas sortir du core c’est « mot » puisque les autres objets, si ils utilisent des mots doivent le prévoir dans leur code. Ca semble être une des définitions d’une fonction core non ?
Donc deux solutions :
une distribution bikini qui contiendra toujours les mots (je pense que les autres sujets sont plus des erreurs)
Surtout pas réintégrer ! L'interet de la découpe ne se limite pas à l'idée de faire tourner le côté sans les mots. Il permet de cloisonner le code et d 'en définir les interfaces. Il ne faut pas revenir en arrière sur ce point.
Et qu'il reste une interface non formalisée qui empêche l'indépendance stricte est certes dommage mais pas bloquant. On a le droit de trouver la solution plus tard.
Surtout pas réintégrer ! L’interet de la découpe ne se limite pas à l’idée de faire tourner le côté sans les mots. Il permet de cloisonner le code et d 'en définir les interfaces. Il ne faut pas revenir en arrière sur ce point.
Je trouve un peu dommage que tu ne répondes pas plutôt à la question qui est : est ce que sortir mots du core a un sens ?
Après cette histoire de mise en plugin à tout prix me parait plus dogmatique aujourd’hui qu’autre chose.
Pourquoi perdrait-on l’interface que tu as améliorée en rentrant mots dans le core ?
Qu’en est-il d’article et de rubrique justement ?
Et qu’il reste une interface non formalisée qui empêche l’indépendance stricte est certes dommage mais pas bloquant. On a le droit de trouver la solution plus tard.
Ca ne me gêne pas non plus si on définit clairement la distribution minimale, oui.
Heu, ce n'est pas ma question ça !
Et pour répondre oui, ça a un sens, et non, ça m'a pas de sens de le remettre dans le core ! Enfin tout de même, pourquoi on ferait ça ? On n'a pas besoin des mots systématiquement...
Bah non, si tu fournis un squelette Z générique… il pourrait très bien fonctionner sans le plugin mots…
Or quid des {id_mots?} qui sont dedans. Cela est pareil pour id_site? id_breve? et j’en passe
Le problème n’est pas spécifique aux mots, même si c’est le seul qui reste dans les fichiers du core.
J’y ai répondu aussi à ta question, ne me fait pas dire ce que j’ai pas dit.
Et pour répondre oui, ça a un sens, et non, ça m’a pas de sens de le remettre dans le core !
Dogme ou argument ?
Enfin tout de même, pourquoi on ferait ça ? On n’a pas besoin des mots systématiquement…
Pourtant le code dit le contraire…
Donc y a forcément un problème conceptuel à la base.
Maintenant, c’est peut-être pas non plus la solution de laisser mots dans le core d’une façon ou d’une autre, parce qu’avoir une distribution bikini avec mots c’est quand même bien accepter que le core nécessite les mots.
Donc Cerdic a peut-être raison en disant que la vérité est ailleurs, plus tard…
Et pour répondre oui, ça a un sens, et non, ça m'a pas de sens de le
remettre dans le core !
Dogme ou argument ?
arguments par ordre décroissant d'importance :
#1 sortir une fonctionnalité du core permet de définir proprement des
API de communication entre les différents éléments, sans trop présager
"en dur".
#2 une fonctionnalité sortie peut être plus facilement mise en
concurrence avec une autre implémentation ; ainsi par exemple pour
textwheel il a fallu ruser pour contourner inc/texte, qui était resté
"en dur".
Surtout pas réintégrer ! L’interet de la découpe ne se limite pas à l’idée de faire tourner le côté sans les mots. Il permet de cloisonner le code et d 'en définir les interfaces. Il ne faut pas revenir en arrière sur ce point.
Je trouve un peu dommage que tu ne répondes pas plutôt à la question qui est : est ce que sortir mots du core a un sens ?
Après cette histoire de mise en plugin à tout prix me parait plus dogmatique aujourd’hui qu’autre chose.
Non, ça a plein d’intérêts concrets sur l’organisation du code et son extensibilité.
Pourquoi perdrait-on l’interface que tu as améliorée en rentrant mots dans le core ?
Je parle de l’interface technique, qu’on ne prend pas la peine d’expliciter quand tout le code est entremellé, alors que la séparation nous contraint à le faire.
si je peux me permettre (n'étant qu'un amateur qui suit spip depuis dix ans)
Non tous le monde n'a pas besoin des mots. mais tout le monde n'a pas besoin non plus d'une hiérarchie du contenu sous la forme rubrique/sousrubrique/article.
Or spip3 permettrait aujourd'hui probablement d'externaliser ce dispositif de classement hiérarchique des contenus dans une extension.
En fait, le classement hiérarchique des contenus et la navigation transversale et non hiérarchique dans ceux-ci via les mots clés peuvent être des fonctions relatives aux objets édoriaux et à leur agencement.
Et en la matière, spip va très loin mais reste sous-exploité pratiquement. Notamment parce que souvent on est obligé de ruser avec le dispositif généralisé rubrique/sous-rubrique (bien qu'il y a moyen de contourner cela, mais justement en rusant).
Je ne pense pas être le seul à aimer spip parce qu'il est un framework, et plus seulement un cms prêt à l'emploi.
Alors, pour ma (très petite) part, allez le plus loin possible dans un core nu, et dans des extensions bien foutues comme vous savez les faire, qui devraient permettre de livrer au bout du compte des distrib "personnalisées" en fonction des besoins.
Par contre je serais demandeur de pouvoir désactiver certaines extensions dans l'interface de gestion des plugin, question de voir ...
Merci pour votre travail !
Spip est exceptionnel dans sa façon de se développer (et dans son résultat).
* Matthieu Marcillaud tapuscrivait, le 31/12/2011 16:07:
Hello,
Comme dit je ne sais où récemment, Le core de SPIP peut presque
fonctionner seul (ie sans aucune extensions, c'est à dire sans aucun des
plugins qui ont été sortis du core).
Il reste 2 (je crois) plugins qui résistent : mots & dist
Je passe volontairement sur la dist, qui en absence fait des "voir en
ligne" => 404
Je m'intéresse dans un premier temps au cas de mots.
Le point noir est la présence dans prive/objets/liste/(articles.html |
rubriques.html) de critères optionnels {id_mot ?}
Lorsque le plugin mots n'est pas là, le compilateur râle à juste titre
de ne pas connaître de jointures possibles avec id_mot.
Je vois 2 actions possibles :
- enlever {id_mot ?} de ces squelettes, et que le plugin mots surcharge
ces boucles, soit en surchargeant le fichier, soit via le pipeline
pre_boucle ? . Cela me semble une mauvaise solution car il y a d'autres
lieux où le problème peut se poser : par exemple dans un squelette
distribué généraliste, qui peut avoir les mêmes critères.
- trouver un mécanisme pour dire : ce critère peut être en erreur
(introuvable), mais c'est normal, pas d'affolement. Par exemple en
utilisant le caractère @ comme en php : {@id_mot ?} ou un second point
d'interrogation {id_mot ??} ...
Quelqu'un a t'il des avis ou des idées là dessus ?
D'après moi, tout comme {id_mot ?} signifie déjà : ne pas en tenir compte
si pas dans l'environnement, il faudrait "juste" que ce ne pas en tenir compte soit indépendant de l'existence de la définition du critère en question.
Donc, qu'il y ait un "catch all" générique de {moncritère ?} qui fasse que si mon critère n'est pas défini, le compilateur se contente de l'ignorer (peut-être avec un log pour ceux qui déboguent leurs squelettes).
je suis à distance vos discussions et la mise au point de spip 3 (que je n'ai pas encore testé) mais il me semble que s'il doit il y avoir plusieurs distribution de bikini (j'aime bien) à tutti quanti, il doit il y avoir une distribution par défaut qui va permettre de conserver le même comportement que la version précédente 2.1.
Il ne doit pas être nécessaire de charger une demi-douzaine d'extension ou plugins pour conserver l'existant.
mes deux sous d'un utilisateur de plus en plus distant!!!
Et pour ne pas perdre plus d'erreurs qu'on ne le veut précisément :
avec un define pour déclarer les tables ou les termes sur lesquelles ces erreurs ne sont pas activées ?
Ce qu'on nomme la distribution SPIP 3.0, celle par défaut, c'est bien ce que tu dis : c'est SPIP Core + la série d'extensions qui va bien, aux mêmes fonctionnalités que 2.1, et qui en fait même plus d'ailleurs.
Ce qu'on nomme SPIP Core, c'est le noyau de SPIP, sans aucune extension installées.
Ce qui est nommé SPIP Bikini actuellement, c'est SPIP Core + 2 extensions qui font que sans elles SPIP Core affiche parfois des erreurs. C'est à dire, c'est actuellement la distribution minimale possible de SPIP, vu que sans il y a des erreurs. C'est bien sur ce point pas très gênant réellement pour SPIP 3 qu'il serait bien, tant qu'à faire de faire mieux, mais comme dit Cédric, ça peut aussi attendre SPIP 3.1. Faire mieux, c'est permettre que le Core fonctionne seul et sans erreur. À partir de là, SPIP Bikini disparaît, plus besoin d'en parler.
Et ce que c'est sympa quand un membre de la *team officielle* ( )
nous explicite quelques vocables....
cela permettra peut-etre de suivre mieux,
voire de mieux participer !
Merci MarciMat
et tous mes voeux a suivre le programmer3 !!
Ce qu'on nomme la distribution SPIP 3.0, celle par défaut, c'est bien ce
que tu dis : c'est SPIP Core + la série d'extensions qui va bien, aux
mêmes fonctionnalités que 2.1, et qui en fait même plus d'ailleurs.
Ce qu'on nomme SPIP Core, c'est le noyau de SPIP, sans aucune extension
installées.
Ce qui est nommé SPIP Bikini actuellement, c'est SPIP Core + 2
extensions qui font que sans elles SPIP Core affiche parfois des
erreurs. C'est à dire, c'est actuellement la distribution minimale
possible de SPIP, vu que sans il y a des erreurs. C'est bien sur ce
point pas très gênant réellement pour SPIP 3 qu'il serait bien, tant
qu'à faire de faire mieux, mais comme dit Cédric, ça peut aussi attendre
SPIP 3.1. Faire mieux, c'est permettre que le Core fonctionne seul et
sans erreur. À partir de là, SPIP Bikini disparaît, plus besoin d'en
parler.
MM.
Et ce que c'est sympa quand un membre de la *team officielle* ( )
+++1
nous explicite quelques vocables....
cela permettra peut-etre de suivre mieux,
voire de mieux participer !
)
)