En réfléchissant au nouveau compilo et au fait que ce qui intéresse
Emmanuel, ça m'a donnée des idées que je vous soumets ici.
En règle générale, un langage informatique, est constitué de grands types de
fonctionnement que l'on retrouve en partie dans SPIP
- des fonctions/procédures : les INCLURE
- des boucles : celles de spip sont «limitées» au parcourt de lignes dans le
résultat d'une requête SQL
- des entrée/sorties : entrée : paramètres dans l'URL (mais pas de balises
spécifiques SPIP pour une saisie de l'utilisateur) et sortie #BALISE SPIP
- des conditions : là encore, uniquement valables sur les résultats d'une
requête SQL
- des affectations de variables : uniquement les #BALISES d'un résultat
d'une requête SQL
- j'en oublie peut-être...
Ces limitations conduisent à utiliser de php les dépasser.
Une extension encore plus poussée des possibilités du langage des squelettes
de SPIP pourrait peut-être réduire encore l'usage du php ?
Il me semble que les boucles ont été inventées pour faciliter au maximum toute
requête d'affichage. Et rendre accessible ce type de calcul, à l'utilisateur
lambda.
Dire que le système des boucles s'approche d'un langage de programmation à
part entière est un pas que je ne franchirais pas. Il ne s'agit que de
"mysql_query (SELECT" (pour parler vulgairement) et d'imbrications entre
celles-ci, aussi puissantes soient elles.
Les conditions sont purement booléennes. La marge de manoeuvre relativement
faible.
Ce qu'apporte Emmanuel avec son compilo s'intègre parfaitement dans la
démarche initiale des boucles, puisqu'il s'agit d'étendre le champ de vision
des requêtes SQL possible (nouveaux champs, nouvelles tables, nouvelles
conditions SQL, etc).
Enfin je dirais que PHP a été conçu pour schématiser, dans l'optique de
vulgariser du C et de rendre accessible à tous, un moyen de faire des pages
web dites dynamiques (et bien plus encore, mais ce n'est pas le sujet). Son
succès, nous le connaissons tous.
Vulgariser, ce qui a été déjà été vulgarisé, est ce bien nécessaire?
Et ben, voila que le debat monte d'un cran ...
Les boucles Spip sont elles un language ? un framework ? un progiciel ? une
uzine à gaz ? ...
Voila bien de grandes questions philosophiques que je me garderai d'aborder.
Une chose est sure, ces boucles, c'est bien pratique.
C'est vrai qu'à la base, les boucles sont plus proches des tags
personnalisés de java, on definit une syntaxe qui genere du code.
Il y a des tag sql dans JSTL, personnellement, je trouve la syntaxe des
boucles plus riche que les simples tags.
Les puristes sauteront au plafond à l'idée de traiter le modele de données
en meme temps que les vues, n'empeche, ca marche, c'est facile à maintenir,
on "produit" vite ... alors qu'on l'appelle language, framework ou autre
chose, l'important est de savoir ce qu'on peut et ce qu'on veut faire avec.
Je rejoins les precedantes discussions en constatant qu'il y a encore des
manques.
Mais si peu !
Le systeme de filtre est très puissant mais ne s'applique qu'à une balise,
on ne peut pas (?) traiter plusieurs balises d'un coup, sauf à créer sa
propre balise (formulaire par exemple)
C'est aujourd'hui le seul cas qui m'impose un affreux mic mac de PHP dans
mes boucle hormis des tests logiques.
Si on veut eliminer le PHP des boucles, il me semble donc important de créer
une syntaxe permettant de gerer à minima des condition, et peut etre des
boucles "programmées" (ou le nombre d'itération ne depend pas de données en
base).
En gros, sur JSTL, c'est le package "core" (c: ...).
Pour ce qui est des traitements de plusieurs balises, je n'ai pas trop
d'idées, mais la finalité est d'appeler une fonction prenant les valeurs de
plusieurs balises en argument, ca ne doit pas etre le bout du monde.
Le systeme de filtre est très puissant mais ne s'applique qu'à une balise,
on ne peut pas (?) traiter plusieurs balises d'un coup, sauf à créer sa
propre balise (formulaire par exemple)
Mais si. Si tu filtres #ID_ARTICLE ton filtre a le droit d'aller chercher
tous les éléments dont il a besoin dans la base.
Je ne suis pas sûr de comprendre les extensions souhaitées dans cette discussion, mais à la lecture des différents squelettes qui circulent,
j'ai tout de même l'impression que Spip souffre plus d'une sous-utilisation
que de limitations intrinsèques. Je m'explique.
La 2e passe de PHP n'est vraiment nécessaire que pour produire du code dépendant du demandeur (est-il authentifié et si oui quels sont ses droits), car il serait abusif de mettre autant de pages en cache que de demandeurs potentiels. Cette brèche est souvent exploitée pour interpoler
dans les squelettes du php qui ne cherche pas à autentifier, ce qui est
inefficace quant au cache, et souvent peu lisible, alors qu'un peu de réflexion amènerait une solution avec un filtre, d'autant plus facile
à trouver maintenant qu'on peut mettre des balises dans ses arguments
(par exemple #TITRE|monfiltre{#ID_ARTICLE}).
On peut transposer le problème avec les langues humaines: ce n'est pas
en multipliant les mots et les règles de grammaire du français que l'on
va aider ce qui ont du mal à s'exprimer en français; le pb est ailleurs.
Je pense donc qu'un squelette ne DEVRAIT interpoler du PHP qu'en cas de
bessoin d'authentification, et quand je dis "devrait" c'est une injonction
au deux groupes concernés:
- aux rédacteurs de squelettes, d'utiliser prioritairement des filtres;
- aux développeurs de Spip, de proposer les constructions les plus expressives possibles.
Je suis d'accord avec Stéphane sur l'absence de boucles à nombre itération plus souple que les variantes autour du LIMIT de SQL, j'avais mentionné le
pb à propos du cas "trouver le premier article avec une petition": là il y a
motivation pour une extension.
Et les différents squelettes qui circulent montrent aussi qu'en priorité
il y a des bugs à corriger dans les dernières extensions proposées: j'y retourne !