Bonjour,
Emmanuel, je suis étonné de ce dépot. Je pensais aussi que cela pouvait fonctionner. Ce n'est donc pas le cas ?
http://zone.spip.org/trac/spip-zone/changeset/34171
Ça m'étonnerait que ce soit la seule occurrence de toute la zone ?
Sur les 4368 squelettes du répertoire spip-zone/_squelettes_ il semble bien que si.
Committo,Ergo:Sum
C'est valable pour les inclusions # et < ?
Comment gérer les conditions si on ne doit pas mettre de crochets ? (je n'avais jamais constaté que ça ne fonctionnait pas, du moins pas tout le temps)
Sur ce cas précis par exemple :
<INCLURE{fond=noisettes/header/header,title=[avant - (#TITRE|attribut_html|texte_script) - après]}
en #SET/GET ?
Ou sur du :
[(#INCLURE{fond=noisettes/article[-(#GET{variante_article})],id_article,env})]
en #SET/GET aussi ?
?
Merci 
Ca ne concerne que l'inclusion avec "<", qui est particulièrement pénible à analyser syntaxiquement,
et qui perturbe inutilement les éditeurs HTML ou XML quand on leur soumet des squelettes avec ça.
Je suis partisan de déclarer obsolète cette construction, et de la remplacer par #INCLURE**.
Je suis de plus assez sceptique sur l'intérêt même de cette inclusion "dynamique":
elle visait à ne pas recalculer plusieurs fois un squelette inclus par plusieurs autres,
mais la mécanique derrière est si lourde qu'on peut s'interroger sur l'existence réele d'un gain.
Son seul intérêt est de forcer un recalcul à chaque visiteur quand la page dépend de ça,
mais ce qui serait alors vraiment utile c'est d'analyse un squelette inclus pour savoir s'il tombe
ou non dans cette catégorie et agir au mieux.
Committo,Ergo:Sum
* Emmanuel Saint-James tapuscrivait, le 04/01/2010 18:19:
C'est valable pour les inclusions # et< ?
Comment gérer les conditions si on ne doit pas mettre de crochets ? (je n'avais jamais constaté que ça ne fonctionnait pas, du moins pas tout le temps)
Sur ce cas précis par exemple :
<INCLURE{fond=noisettes/header/header,title=[avant - (#TITRE|attribut_html|texte_script) - après]}Ca ne concerne que l'inclusion avec "<", qui est particulièrement pénible à analyser syntaxiquement,
et qui perturbe inutilement les éditeurs HTML ou XML quand on leur soumet des squelettes avec ça.
Je suis partisan de déclarer obsolète cette construction, et de la remplacer par #INCLURE**.Je suis de plus assez sceptique sur l'intérêt même de cette inclusion "dynamique":
elle visait à ne pas recalculer plusieurs fois un squelette inclus par plusieurs autres,
mais la mécanique derrière est si lourde qu'on peut s'interroger sur l'existence réele d'un gain.
Son seul intérêt est de forcer un recalcul à chaque visiteur quand la page dépend de ça,
mais ce qui serait alors vraiment utile c'est d'analyse un squelette inclus pour savoir s'il tombe
ou non dans cette catégorie et agir au mieux.
C'est aussi assez utile pour avoir un squelette englobant avec un temps de cache important.
Et un squelette inclus avec un temps de cache plus faible.
Emmanuel Saint-James a écrit :
C'est valable pour les inclusions # et < ?
Comment gérer les conditions si on ne doit pas mettre de crochets ? (je n'avais jamais constaté que ça ne fonctionnait pas, du moins pas tout le temps)
Sur ce cas précis par exemple :
<INCLURE{fond=noisettes/header/header,title=[avant - (#TITRE|attribut_html|texte_script) - après]}
Ca ne concerne que l'inclusion avec "<", qui est particulièrement pénible à analyser syntaxiquement,
et qui perturbe inutilement les éditeurs HTML ou XML quand on leur soumet des squelettes avec ça.
Je suis partisan de déclarer obsolète cette construction, et de la remplacer par #INCLURE**.
tu plaisantes j'espère ?
c'est TRES utile de pouvoir maitriser le contexte d'une inclusion de facon programmé (que ca soit pour faire des caches personnels, par statut, ou tout simplement dépendant d'une donnée qui n'est pas connue dans le squelette appelant).
Au niveau perf, les balises SESSION et AUTORISER me paraissent beaucoup plus discutables qu'une inclusion ajoutant les informations necessaires au contexte.
Si c'est juste une question de syntaxe, il suffirait de permettre (aussi) l'ecriture en <INCLURE ... />
mais bon, les boucles et le chaines internationalisées affolent bien plus mon editeur que les inclusions...
@++
J'etais passé au tout #INCLURE, mais j'en suis revenu car cela fait perdre le dynamisme des #FORMULAIRE_xx qui sont du coup stocké en cache avec les valeurs proposées au dernier visiteur qui a provoqué le calcul du cache.
Typiquement, le formulaire de login dans un #INCLURE de #INCLURE entrainait le stockage en cache du login d'un visiteur.
Donc il manque clairement des outils pour cela se passer de <INCLURE> à ce stade.
Cédric
J'ai du mal m'exprimer pour que vous soyez 3 à enfoncer des portes que nous savons tous ouvertes.
Je disais donc que
1. la SYNTAXE de <INCLURE ...> est moins puissante que #INCLURE à cause des crochets (manque qui a démarré ce fil) et fait partie des constructions syntaxiques de SPIP peu appréciées des éditeurs, donc je propose que la SEMANTIQUE de cette construction soit disponible autrement, par exemple par la SYNTAXE avec double étoile, soit #INCLURE** (puisqu'avec une seule étoile ça existe déjà).
2. je sais que ce type d'inclusion permet d'avoir des caches différents, mais justement je disais que je suis sceptique sur les gains que ça représente, d'autant qu'à supposer qu'ils existent, il faut un degré d'expertise peu fréquent et une disponibilité encore plus rare pour faire la palanquée de mesures qui les garantiraient.
3. tant qu'à remettre en cause cette construction, je sous-entendait qu'il faudrait PROGRAMMER des outils qui décideraient de la SEMANTIQUE la plus adaptée à la situation, savoir la dynamique (celle de l'actuelle <INCLURE..>) s'il y a des choses dans le squelette inclus qui doivent être recalculées à chaque fois (typiquement un formulaire) ou la statique (celle de l'actuelle #INCLURE) si ce n'est pas le cas et qu'on partage mon scepticisme quant au point 2.
C'est clair cette fois ?
Committo,Ergo:Sum
J'ai du mal m'exprimer pour que vous soyez 3 à enfoncer des portes que nous savons tous ouvertes.
Je disais donc que1. la SYNTAXE de <INCLURE ...> est moins puissante que #INCLURE à cause des crochets (manque qui a démarré ce fil) et fait partie des constructions syntaxiques de SPIP peu appréciées des éditeurs, donc je propose que la SEMANTIQUE de cette construction soit disponible autrement, par exemple par la SYNTAXE avec double étoile, soit #INCLURE** (puisqu'avec une seule étoile ça existe déjà).
Ah ok.
Mais n'est-ce pas un leurre syntaxique, puisque de par la nature meme de l'inclusion dynamique
[(#INCLURE**{}|filtre)]
ne sera pas possible ?
A moins de le dénoncer à la compilation ?
2. je sais que ce type d'inclusion permet d'avoir des caches différents, mais justement je disais que je suis sceptique sur les gains que ça représente, d'autant qu'à supposer qu'ils existent, il faut un degré d'expertise peu fréquent et une disponibilité encore plus rare pour faire la palanquée de mesures qui les garantiraient.
oui, je suis bien d'accord sur ce point
Cédric
Ou plutôt compiler [(#INCLURE**{X}|f} en
<?php ob_start(); recuperer_fond(X); echo f(ob_get_contents()); ob_end_clean() ?>
Committo,Ergo:Sum
Emmanuel Saint-James a écrit :
J'ai du mal m'exprimer pour que vous soyez 3 à enfoncer des portes que nous savons tous ouvertes.
ben non, c'est moi qui doit mal m'exprimer ou alors tu envisages un grand bond en avant de l'analyseur ...
J'utilise les <INCLURE> pour appeler un script php qui mets en place le contexte souhaité, ou fait un aiguillage de squelette (typiquement, un bloc renvoyant un squelette pour le grand public, un autre pour les utilisteurs authentifiés sans droits et un troisieme pour les utilisateurs autorisé) ou fait d'autres trucs DYNAMIQUES en PHP
<INCLURE est aussi un bon outil d'integration permettant de créer une facade entre une application et SPIP tout en profitant du cache de Spip (au moins pour la partie présentation)
je vois mal comment faire ca avec #INCLURE...
De plus, pour moi, tout l'interet de #INCLURE est justement de pouvoir découper en petit squelettes pour simplifier la maintenance sans pour autant dégrader les perfs en allant lire plein de petits fichiers pour les assembler, avec #INCLURE, il n'y a bien qu'un cache généré (si tu fais 50 <INCLURE>, les perfs s'ecroulent sur certains mutualisés, free en particulier).
Laisser l'analyseur décider de faire un ou plusieurs cache et ne pas savoir en ecrivant le squelette appelant ce qu'il va se passer à la compilation ? non merci !
D'ailleurs quelque part, cela obligerait à avoir tous les squelettes inclus pour pouvoir compilé le squelette appelant, ce qui est en soit pas génial.
M'enfin, si tu veux compliquer l'analyse pour améliorer #INCLURE, pourquoi pas (quoi que, encore une fois, changer le delai de cache d'un squelette inclus ne devrait pas à mon sens changer la compilation du squelette appelant), mais soit sympa, ne casse pas le fonctionnement de <INCLURE>, ne serait-ce que pour la compatibilité.
@++
Si tu as une noisette qui affiche une citation que tu veux voir changer à chaque fois, il est quand même plus performant d'avoir un squelette englobant avec un cache long, et la noisette avec un cache de zéro, non ?
-Nicolas
Ok merci
Et avec le reste de la discussion, je crois que j'ai appris plein de trucs... Reste à voir ce que je vais en faire 
Nicolas Hoizey a écrit :
Mais comment le compilateur pourrait-il décider pour moi si je veux que la citation se mette à jour à chaque fois, ou toutes les 10 secondes, ou une fois par heure ???
-Nicolas
Nicolas Hoizey a écrit :
Salut,
Puisque vous êtes en train de réfléchir aux inclusions et au cache, il y a deux choses qui me semblent intéressantes à considérer:
- le système de microcache qu'on utilise sur rezo.net (le code est dans la zone): c'est une inclusion en dur de chez dur (on calcule la noisette, on stocke le résultat HTML, et on l'intègre en HTML dans la page). Ça permet de gagner énormément de temps, puisqu'il n'y a plus aucun automatisme de SPIP lié à ce fichier.
- dans le système de microcache: on connaît le nom du fichier en cache. Ce qui serait chouette: la possibilité de forcer le nom du fichier de cache. Genre:
#NOM_CACHE{lenom#ID_AUTEUR-#ID_ARTICLE}
L'avantage, c'est que ça permet de travailler sur des fichiers de cache «permanents» qu'on peut décider de supprimer depuis des fonctions utilisées ailleurs sur le site.
Arnaud
Ah bin oui... en comparant les deux durées de caches, en fait...
-Nicolas
C'est exactement le résultat que l'on obtient avec #INCLURE, non ?
Cédric
cedric.morin@yterium.com a écrit :
Salut,
Puisque vous êtes en train de réfléchir aux inclusions et au cache, il y a deux choses qui me semblent intéressantes à considérer:
- le système de microcache qu'on utilise sur rezo.net (le code est dans la zone): c'est une inclusion en dur de chez dur (on calcule la noisette, on stocke le résultat HTML, et on l'intègre en HTML dans la page). Ça permet de gagner énormément de temps, puisqu'il n'y a plus aucun automatisme de SPIP lié à ce fichier.
C'est exactement le résultat que l'on obtient avec #INCLURE, non ?
si j'ai bien compris, #INCLURE va plutot agréger les squelettes compilés donnant un unique squelette compilé qui génèrera un cache global (pouvant contenir éventuellement du PHP) alors qu'ici, il parle d'injecter dans le squelette compilé le résultat (cad le cache lui meme) et et meme plutot le resultat de l'execution de ce cache si je comprend bien (exec du php s'il y en a)
Mais j'ai du comprendre un truc de travers sur le #INCLURE vu que tu parles de probleme s'ils contiennent des balises dynamiques...
@++