http://trac.rezo.net/trac/spip/changeset/14447
devrait clore proprement toute cette discussion
Je suis bien d'accord. Mais le fait est qu'on a pas les mêmes problèmes de fond 
Sur le cas particulier de #SET et #GET.
Si il s'agit juste de les enlever du squelette-dist actuel pour ne pas heurter les debutants soit. Ca ne me gêne pas, même si je ne partage pas ton point de vue.
Si il s'agit de les virer car elles te semblent inutiles et superflues alors par contre je ne suis pas du tout d'accord.
Cédric
En revanche, je défends le fait qu'il serait bon de consacrer le maximum de nos échanges à des pbs de fond.
Je suis bien d'accord. Mais le fait est qu'on a pas les mêmes problèmes de fond
Nous avons en commun le pb de fond que le langage des squelettes reste facile à comprendre,
je suis surpris que tu puisses dire que cela ne serait pas un problème pour toi.
Les changements que l'on fait dans le core ne sont pas du même ordre que ceux qu'on fait sur la zone:
dans le dernier cas ça ne concerne que ceux qui décideront d'utiliser cette extension,
dans l'autre cas ça concerne tout le monde, ce sont donc des problèmes communs, et de fond.
Sur le cas particulier de #SET et #GET.
Si il s'agit juste de les enlever du squelette-dist actuel pour ne pas heurter les debutants soit.
oui, ça me paraît indispensable au besoin de donner rapidement le sentiment à un nouveau venu qu'il a compris les bases de SPIP.
Ca ne me gêne pas, même si je ne partage pas ton point de vue.
Si il s'agit de les virer car elles te semblent inutiles et superflues alors par contre je ne suis pas du tout d'accord.
Je reprends ma comparaison avec la transformation de HTML 3.2 en XHTML+CSS: quantité de balises et attributs ont disparu de HTML, mais leur fonctionnalité se sont retrouvées dans les CSS, et en beaucoup mieux parce que ça établissait une frontière claire entre le balisage du fond (par HTML) et sa mise en forme (par les CSS). SPIP est devenu un langage très riche (ce qui est une bonne nouvelle à beaucoup de points de vue), et il est donc normal de poser la question de son éclatement en entités fonctionnelles appréhendables indépendamment. Ce n'est pas porter un jugement sur l'intérêt respectif de ces entités: HTML sans CSS c'est abominable quoique fonctionnel, un SPIP sans aucune "balise SPIP" serait probablement du même tonneau, mais dans les deux cas ce n'est pas un argument pour refuser la démarche.
Committo,Ergo:Sum
PS: ok pour la solution à form_hidden; lorsque j'avais soulevé le pb dans
http://comments.gmane.org/gmane.comp.web.spip.devel/53257
c'est dommage que personne n'ait alors vu que nettoyer_url_page pouvait le résoudre rapidement. On a perdu 4 mois.
Il m’arrive de relire certains commits un peu trop vite, ou d’un oeil pas assez attentif, il faut croire.
mea culpa.
Pour cette rentrée 2009, je vais m’attacher à être plus régulier dans mes corrections, alors.
Cédric, mode trolleur
El Wednesday 02 September 2009 08:02:27 Committo,Ergo:sum va escriure:
Je reprends ma comparaison avec la transformation de HTML 3.2 en
XHTML +CSS
Sans prendre part dans le débat initial, je voudrais juste faire une
remarque sur ce parallèle avec XHTML / CSS.
J'aime bien l'idée de prendre ce parallèle, et il pourrait être
intéressant d'appliquer un concept similaire à SPIP. Par contre je vois
pas bien comment pour l'instant (mais j'aimerais bien).
En particulier, bien que je comprenne le parallèle que tu fais avec le
couple core / plugins, je me dis que la comparaison a ses limites, parce
que CSS n'étend pas les fonctionnalités de XHTML : ça ne rajoute pas de
balises HTML, d'attributs possibles, etc. Ce sont deux espaces
orthogonaux, si on veut (indépendants et complémentaires). En revanche,
les plugins jouent exactement sur le même _domaine_ syntaxique que le
core : la seule conséquence d'un "déplacement" d'une fonctionnalité en
plugin se situe dans la localisation du code, mais en termes de
fonctionnalités et d'utilisation, pour l'utilisateur c'est la même
chose. L'équivalent de ça en XHTML serait si le W3C déléguait l'ajout de
balises HTML a une autre autorité, et que les nouvelles devaient être
déclarées avec un namespace supplémentaire dans le code. Ça serait
intéressant, mais pas du même ordre que la séparation fond/forme de
XHTML et CSS.
Pour clarifier la différence : pour une conception de site web, une
personne peut travailler sur l'écriture ou la génération de HTML, et une
autre sur la partie CSS. Ce n'est pas le cas (ni le but) avec les outils
fournis par le core et ceux fournis par les plugins. Par contre l'idée
m'intéresse vraiment, mais je cherche encore comment l'idée pourrait
s'appliquer à SPIP pour structurer l'API.
Sans prendre part dans le débat initial, je voudrais juste faire une
remarque sur ce parallèle avec XHTML / CSS.
...
En particulier, bien que je comprenne le parallèle que tu fais avec le
couple core / plugins, je me dis que la comparaison a ses limites, parce
que CSS n'étend pas les fonctionnalités de XHTML
Oui, faire la comparaison avec C et son pré-processeur de macros ou ses extensions objet comme C++ serait plus proche de SPIP et ses balises, mais c'est une culture moins partagée sur cette liste que XHTML/CSS.
A la base, on peut tout faire avec les 5 mots-clés autour de BOUCLE, les filtres avec | et {}, et enfin les champs étendus [...(#...)...] mais limités à l'extraction de champ SQL (y compris la table des meta, accessible hors boucle). Les "balises SPIP" ne sont finalement que des abréviations pour des compositions des éléments pré-cités, repérées comme particulièrement fréquentes et/ou utiles. Elles sont donc à SPIP ce que les macros sont à C, et d'ailleurs ce serait mieux de toujours les implémenter comme des macros (et non comme des fonctions comme c'est souvent le cas actuellement), pour que l'optimiseur puisse opérer plus facilement.
Mais foin de ce détail technique, l'idée est est de voir un ensemble de "balises SPIP" comme une bibliothèque d'extensions, et chaque site ne prendrait que celles qui l'intéresse. Historiquement, SPIP a commencé comme générateur de Webzine, il y a donc quantité de balises propres à cet univers qui ne vont pas intéresser d'autres applications: si j'utilise SPIP comme une galerie de photos sans autre texte que leur titre, qu'ai-je à faire des balises LOGO_*, URL_*, LES_AUTEURS et j'en oublie surement ?
Du reste, le retrait hors du noyau de la table des forums s'est accompagné du retrait de la balise PARAMETRES_FORUM, pas seulement des squelettes et scripts de l'espace privé associés. Si on va jusqu'au bout de la logique, combien de balises SPIP apparaîtront indispensable au noyau ? Très peu, et même zéro si on introduit quelques critères ou filtres bien choisis.
Committo,Ergo:Sum
Je rebondis sur cette conversion du 2 septembre, où esj écrivait :
Elles sont donc à SPIP ce que les macros sont à C, et d'ailleurs ce serait mieux de toujours
les implémenter comme des macros (et non comme des fonctions comme c'est souvent le
cas actuellement), pour que l'optimiseur puisse opérer plus facilement.
J'aimerais bien qu'on ait des macros, mais à quoi est-ce que ça
ressemblerait ? Actuellement le seul cas que je connaisse de balise
écrite en macro,c'est #LESAUTEURS, qui appelle un modèle. Est-ce que
c'est comme ça que tu les envisages ?
Du reste, le retrait hors du noyau de la table des forums s'est accompagné
du retrait de la balise PARAMETRES_FORUM, pas seulement des squelettes et
scripts de l'espace privé associés. Si on va jusqu'au bout de la logique,
combien de balises SPIP apparaîtront indispensable au noyau ? Très peu, et
même zéro si on introduit quelques critères ou filtres bien choisis.
Ce serait bien qu'on adopte une convention pour décrire ce qui est du
noyau du langage, et ce qui relève (ou devrait relever, ou relèvera, à
terme) des macros.
Prenons l'exemple, très actuel (cf.
http://romy.tetue.net/tetue_trousse ), de la balise #TITRE_PARENT ;
elle est absolument pratique en termes d'usage, et absolument pas
indispensable dans un "langage de base". Que faut-il en faire ?
Selon l'argument pratique, il serait pas mal de la mettre dans le core
; selon l'argument théorique, ça n'est pas indispensable. Comme SPIP
est un mélange des deux, certains penchant plus vers le pratique,
d'autres plus vers le théorique, ça n'aide pas à trouver la réponse.
Ce que je proposerais, pour qu'on puisse développer librement, en
respectant la théorie mais sans se faire corseter par elle, c'est de
marquer cette balise (et d'autres qui relèvent du même principe) d'une
façon qui permette de dire "ça, ça ne fait pas partie du langage de
base".
Tout comme on a mis dans inc/filtres_mini les filtres absolument
indispensables, et inc/filtres les autres, qui sont utilisés en
permanence etc mais qui ne font pas partie du langage "de base".
D'ailleurs, tous comptes fait, c'est peut-être les "BALISES
essentielles" qu'il faut sortir du fichier public/balises.php ...
à vous les studios
-- Fil
Je rebondis sur cette conversion
C'est de la diffamation, je ne me suis jamais converti au christianisme !
du 2 septembre, où esj écrivait :
Elles sont donc à SPIP ce que les macros sont à C, et d'ailleurs ce serait mieux de toujours
les implémenter comme des macros (et non comme des fonctions comme c'est souvent le
cas actuellement), pour que l'optimiseur puisse opérer plus facilement.J'aimerais bien qu'on ait des macros, mais à quoi est-ce que ça
ressemblerait ? Actuellement le seul cas que je connaisse de balise
écrite en macro,c'est #LESAUTEURS, qui appelle un modèle. Est-ce que
c'est comme ça que tu les envisages ?
Je n'envisageais rien de précis encore, ce que je voulais dire simplement
c'est que la méthode actuelle impose de connaître les structures de données du compilateur
pour pouvoir l'étendre, alors que l'approche par macro offre une interface par langage,
plus facile d'accès au non programmeur, et plus facile à maintenir.
Les modèles sont effectivement un pas dans cette direction,
mais il est incomplet.
Ce serait bien qu'on adopte une convention pour décrire ce qui est du
noyau du langage, et ce qui relève (ou devrait relever, ou relèvera, à
terme) des macros.
...
D'ailleurs, tous comptes fait, c'est peut-être les "BALISES
essentielles" qu'il faut sortir du fichier public/balises.php ...
Il faut distinguer le noyau du langage de squelettes et le noyau du CMS SPIP.
Sur le plan de la théorie du langage, le noyau est un ensemble de fonctionnalités minimal,
minimal en ce sens que si on en retire une fonctionnalité, on ne peut pas la reconstruire à l'aide des autres.
Partant, AUCUNE balise de SPIP n'est essentielle, car on peut les reconstruire avec des filtres appliqués
à des champs SQL, et on pourrait considérer qu'elle devraient toute migrer dans des plugins de la zone.
Evidemment, du point de vue du noyau de SPIP ce n'est pas souhaitable parce que les squelettes standards
ne marcheraient plus. Mais ça montre justement que l'organisation des sources n'est pas bonne. Le fichier "balises.php"
n'a rien à faire dans le répertoire du compilateur. Ce serait déjà plus clair si chacune de ses fonctions était dans un fichier homonyme du répertoire "balise". Mais il faudrait réfléchir à une organisation pour les plugins qui permettent
à un plugin d'utiliser les balises d'un autre plugin sans utiliser ses squelettes. Du coup on mettrait les squelettes et les balises habituelles dans un plugin, et on pourrait aller vers un SPIP qui pourrait avoir des noyaux (de CMS) différents, s'appuyant sur un noyau (de langage) méritant le nom de noyau.
Committo,Ergo:Sum