Author: esj@rezo.net
Date: 2009-05-15 08:55:19 +0200 (ven, 15 mai 2009)
New Revision: 13993
Log:
Les balises {{{#INCLURE}}} et {{{#MODELE}}} rentrent dans le rang en acceptant l'écriture {{{#INCLURE{a,b,c} }}}, avec touts les niveaux d'imbrications que l'on souhaite, et avec les crochets pour spécifier les en-têtes et en-pieds conditionnés à la vacuité du résultat de la balise (report de [13392] et [13986]).
Dans un squelette,
[(#INCLURE{#CHEMIN{spip_style.css}|url_absolue_css}|compacte_css)]
provoque l'erreur :
Catchable fatal error: Object of class Champ could not be converted to string in ecrire\public\debug.php on line 218
Le message d'erreur contient en effet une erreur je vais arranger ça,
mais ta syntaxe est fausse car le premier pipe n'est pas contenu dans des parenthèses contenu dans les crochets.
Et il n'est de toutes façons pas question d'accepter une URL comme argument d'INCLURE.
* Emmanuel Saint-James tapuscrivait, le 15/05/2009 16:07:
Dans un squelette,
[(#INCLURE{#CHEMIN{spip_style.css}|url_absolue_css}|compacte_css)]
provoque l'erreur :
Catchable fatal error: Object of class Champ could not be converted to string in ecrire\public\debug.php on line 218
Le message d'erreur contient en effet une erreur je vais arranger ça,
mais ta syntaxe est fausse car le premier pipe n'est pas contenu dans des parenthèses contenu dans les crochets.
Et il n'est de toutes façons pas question d'accepter une URL comme argument d'INCLURE.
Ce n'est pas une URL mais un fichier inclus tel quel par SPIP, et sur lequel il est possible d'appliquer des filtres.
C'est entre autre utilisé dans Connexion · GitLab
En tout cas, je me souviens d'un échange sur la différence entre :
- #INCLURE{fond=squelette} <=> récuperer_fond
- #INCLURE{fichier} <=> include
Les 2 étant sensés fonctionner (et dans mon cas, c'est le 2e qui est utilisé).
En tout cas, je me souviens d'un échange sur la différence entre :
- #INCLURE{fond=squelette} <=> récuperer_fond
- #INCLURE{fichier} <=> include
Les 2 étant sensés fonctionner (et dans mon cas, c'est le 2e qui est
utilisé).
le filtre |url_absolue_css prend le fichier en entrée, et le rééecrit en passant les url contenues en absolues
Il renvoie un nom de fichier, la syntaxe est donc correcte
0 à l'examen (t'as du pot, je viens de voter la non remise des notes):
le résultat d'une fonction est de la sémantique, pas de la syntaxe, c'est un argument irrecevable.
Quand va-t-on cesser de rajouter de l'entropie à SPIP ?
Je n'avais pas vu passer l'introduction de cette syntaxe à l'époque, mais elle est inadmissible car il y en avait déjà une autre qui fournit la même sémantique sans surcharger la mémoire du pauvre utilisateur avec des cas particuliers.
Je considère donc que c'est par hasard que cette syntaxe a marché, et qu'il faut utiliser la bonne.
le filtre |url_absolue_css prend le fichier en entrée, et le rééecrit en passant les url contenues en absolues
Il renvoie un nom de fichier, la syntaxe est donc correcte
0 à l'examen (t'as du pot, je viens de voter la non remise des notes):
le résultat d'une fonction est de la sémantique, pas de la syntaxe, c'est un argument irrecevable.
Quand va-t-on cesser de rajouter de l'entropie à SPIP ?
Je n'avais pas vu passer l'introduction de cette syntaxe à l'époque, mais elle est inadmissible car il y en avait déjà une autre qui fournit la même sémantique sans surcharger la mémoire du pauvre utilisateur avec des cas particuliers.
Je considère donc que c'est par hasard que cette syntaxe a marché, et qu'il faut utiliser la bonne.
Parfait avec 13998.
Par contre, pour info, ça provoque une erreur dans l'espace d'admin avec le plugin agenda 2.
Tout en haut, au dessus du menu :
Parse error: syntax error, unexpected ')' in ecrire\public\composer.php(73) : eval()'d code on line 31
le filtre |url_absolue_css prend le fichier en entrée, et le rééecrit en passant les url contenues en absolues
Il renvoie un nom de fichier, la syntaxe est donc correcte
0 à l'examen (t'as du pot, je viens de voter la non remise des notes):
le résultat d'une fonction est de la sémantique, pas de la syntaxe, c'est un argument irrecevable.
Quand va-t-on cesser de rajouter de l'entropie à SPIP ?
Je n'avais pas vu passer l'introduction de cette syntaxe à l'époque, mais elle est inadmissible car il y en avait déjà une autre qui fournit la même sémantique sans surcharger la mémoire du pauvre utilisateur avec des cas particuliers.
Je considère donc que c'est par hasard que cette syntaxe a marché, et qu'il faut utiliser la bonne.
Parfait avec 13998.
Par contre, pour info, ça provoque une erreur dans l'espace d'admin avec le plugin agenda 2.
Tout en haut, au dessus du menu :
Parse error: syntax error, unexpected ')' in ecrire\public\composer.php(73) : eval()'d code on line 31
* cedric.morin@yterium.com tapuscrivait, le 15/05/2009 18:13:
en quoi l'écriture d'origine n'était pas licite syntaxiquement parlant ?
Elle n'était pas explicite sur le chemin du fichier, qui du coup était à prendre où ? Manifestement, dans le même dossier que le squelette appelant...
Voilà ce que j'ai compris.
* cedric.morin@yterium.com tapuscrivait, le 15/05/2009 18:13:
en quoi l'écriture d'origine n'était pas licite syntaxiquement parlant ?
Elle n'était pas explicite sur le chemin du fichier, qui du coup était à prendre où ? Manifestement, dans le même dossier que le squelette appelant...
Voilà ce que j'ai compris.
Bon, j'ai mal compris d'après ce que tu dis sur la zone : « Et c'est déplorable de devoir faire deux fois un find_in_path puisqu'il est à nouveau refait dans #INCLURE »
Rien à voir : tu avais une erreur de syntaxe avec un bug php, et tu mexpliques que c'est parce que il trouve pas le fichier.
Non il y a un bug dans le compilateur, c'est pas la même chose.
Il est licite de faire #INCLURE{dossier/monfichier.css}
Au pire si le fichier n'était pas trouvé, tu n'aurais rien dans le résultat, mais pas une erreur php.
Et en ce qui concerne la recherche du fichier, cela est pris en compre par le code génére http://trac.rezo.net/trac/spip/browser/spip/ecrire/public/balises.php#L1006
qui inclue un find_in_path
Donc stp, ne patchons pas "n'importe quoi n'importe comment pourvu que ça marche".
Il faut remettre la syntaxe d'origine, qui était bonne, et corriger le core qui lui est faux.
en quoi l'écriture d'origine n'était pas licite syntaxiquement parlant ?
Oui, mais sémantiquement parlant, ça va pas
Tu n'aurais pas du sécher autant les cours !
Par contre, sans rire, ça me gène ces modifications sur le 2.0.x qui font que des écritures ne fonctionnent plus... (pour le moment, tout va bien chez moi !)
Par exemple est-ce que l'exemple ci-dessous est syntaxiquement valide ? (remarque, ça fonctionne encore (ouf !))
si on considère que *la* syntaxe d'écriture d'un filtre c'est
[(OBJET|filtre)]
Ce serait bien que ce soit clair comme ça...
et c'était comme ça a priori jusqu'à ce que des déviations obligatoires
apparaissent en cas d'imbrications...
il faut #SET{left, [(#ENV{ltr}|choixsiegal{left,left,right})]}
et, du coup, car ceci ne fonctionne pas (accolade fermante affichée)
