J'ai posté une nouvelle version du compilateur SPIP sur
http://www.uzine.net/spip_contrib/ecrire/articles.php3?id_article=272
Outre ses innovations (automatisation de la prise en compte d'un champ SQL
en champ SPIP) j'y signale un bug potentiel à propos de la mise à jour
de la base.
Emmanuel
J'ai posté une nouvelle version du compilateur SPIP sur
http://www.uzine.net/spip_contrib/ecrire/articles.php3?id_article=272
Excellent. Je pense qu'on va sortir la 1.7 avant d'intégrer ton code,
histoire de ne pas faire prendre de risques aux sites qui vont faire
l'upgrade. Sinon ça a l'air tout bon. Et merci pour les {1,n-1} 
Tu écris : "(entre autres le champ URL_REF que j?avais oublié dans la
version précédente). " : attention c'est devenu url_site + nom_site (comme
pour les brèves).
Pour maj_base(), elle est censée retourner un code d'erreur en cas de
problème (mais c'est juste un framework inutilisé pour l'instant), et rien
(false) sinon.
-- Fil
Déesse A. wrote:
J'ai posté une nouvelle version du compilateur SPIP sur
http://www.uzine.net/spip_contrib/ecrire/articles.php3?id_article=272
Outre ses innovations (automatisation de la prise en compte d'un champ SQL
en champ SPIP) j'y signale un bug potentiel à propos de la mise à jour
de la base.Emmanuel
_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
cvs: http://www.spip.net/spip-dev/devel/
bonjour Emmanuel
je rentre en boucle infinie, je pense dans cette partie
inc-index-squel.php3 on line 396
case 'TOTAL_BOUCLE':
$n = 0;
$b = $id_boucle;
while ($b != $boucle_courante)
{
$n++;
$b = $boucles[$b]->id_parent;
}
sinon, j'ai du changer un include_ecrire dans inc_calcul_squel.php3
# include_ecrire("inc_kreate.php3");
include_local("inc_kreate.php3");
sinon, une grande partie des boucles semble fonctionner correctement.
Déesse A. wrote:
J'ai posté une nouvelle version du compilateur SPIP sur
http://www.uzine.net/spip_contrib/ecrire/articles.php3?id_article=272
Outre ses innovations (automatisation de la prise en compte d'un champ SQL
en champ SPIP) j'y signale un bug potentiel à propos de la mise à jour
de la base.
j'ai supprimé le point de blocage, et mon site passe presque en intégralité
pourtant c'est un squelette assez complexe, avec bcp de requetes (boucles)
de toute sorte, des filtres, des includes tres nombreux.
seule chose qui passe pas bien, la limitation dans les boucles.
c'est pas encore implanté ?
joli travail ! c'est une alternative interessante et a transition douce
aux autres solutions proposées sur cette liste.
Normalement tout est implanté: je n'ai fait que réécrire le code existant.
Pourrais-tu donner le texte de la boucle qui ne va pas ?
esj
Déesse A. wrote:
seule chose qui passe pas bien, la limitation dans les boucles.
c'est pas encore implanté ?Normalement tout est implanté: je n'ai fait que réécrire le code existant.
Pourrais-tu donner le texte de la boucle qui ne va pas ?esj
il y a celui-ci entre autre :
<!-- start - _box_dernieres_breves.html -->
<?php box_start('box', 'Dernières Brèves', 'messagerie.gif'); ?>
<BOUCLE_breves(BREVES){tout}{par date}{inverse}{0,6}>
<a HREF="#URL_BREVE" title="[(#DATE|jour|attribut_html)]/[(#DATE|mois|attribut_html)]/[(#DATE|annee|attribut_html)]">
<img border="0" src="<?= $GLOBALS['squelette']['img'] ?>/puce_fleche-active.png"></a>
[(#DATE|jour|digits{2})]/[(#DATE|mois|digits{2})] : [(#TITRE|textebrut|titre_homogene|couper_texte_stna{60})]</a>
<br>
</BOUCLE_breves>
<br>
[ <a href="breve.php3">plus de brèves</a> ]
<?php box_close(); ?>
<!-- end - _box_dernieres_breves.html -->
et qui donne domme resultat (j'ai largement plus que 6 breves en sortie) :
cette erreur survient aussi sur d'autres boucles avec criteres de limitation ;
je ne sais pas si ce sont toutes les boucles qui sont affectées.
c'est un boucle tout a fait standard avec aucune subtilité.
Dernières Brèves
12/09 : Prochain GT GED7 : 7 octobre
09/09 : Mise en service V22.3 au CRNA/O
26/08 : Mise en service V22.1 par CRNA/E
12/08 : Mise en service V22.2 par CRNA/O
11/08 : Les docs du PCT sont sous la GED
08/08 : Les indicateurs des EBs sont sous la GED
08/08 : Les docs EDS2003 sont sous la GED.
06/08 : Les documents MCO sont sous la GED
04/08 : Mise en service V22.1 par CRNA/O
04/08 : Fiche de préconisation 01/FPU/03 est disponible sous la GED
29/07 : Support de présentation GED7 sous la GED
29/07 : Procédures de la GED7 sous la GED
23/07 : Automatisation des références STNA 7
23/07 : Cahier des charges paquetage N°4 en relecture au SCTA
23/07 : Les documents APMO sont sous la GED
23/07 : Les documents CIC sont sous la GED
22/07 : Lancement des publications Cautra
22/07 : Le site STR R7 est référencé sous STNA 7VE
22/07 : Le site LDB est référencé sous STNA/7SB
16/06 : Le PCP paquetage cautra N°4 est sous la GED
10/04 : Documents STPV et STR existants sont archivés dans la GED
06/03 : Les documents du Paquetage en route N°3 sont sous la (...)
05/03 : Documents GED 7 archivés sous la GED
10/02 : Documents IVS sont archivés sous la GED
Salut,
> J'ai posté une nouvelle version du compilateur SPIP sur
> http://www.uzine.net/spip_contrib/ecrire/articles.php3?id_article=272Excellent. Je pense qu'on va sortir la 1.7 avant d'intégrer ton code,
histoire de ne pas faire prendre de risques aux sites qui vont faire
l'upgrade. Sinon ça a l'air tout bon.
Hola, t'as envie de maintenir ça tout seul ?
Il faut vraiment faire le tri entre les différentes modifs et distinguer
:
- les corrections de bug
- les bonnes idées (inc_kreate (à renommer), fonction pile_index)
- les optimisations locales inutiles (du genre concaténations combinées
: aucun gain visible, code plus compliqué)
- les trucs qui compliquent ou obscurcissent le code
Aussi, ce serait sympa (lire : très apprécié) :
- de respecter la convention "une indentation = un caractère de
tabulation"
- la nomenclature aussi c'est pas mal (si on utilise id_article
partout, pourquoi réécrire une fonction en remplaçant par id_a ?)
- de ne pas utiliser de code illisible du genre :
« return ($texte . '
$t0 = "' . calculer_requete($id_boucle) . '";
if (!($result = @spip_query($t0))) {
include_local("inc-debug-squel.php3");
return erreur_requete_boucle($t0, "' .
$id_boucle . '", "'.
$type_boucle . '");
}
$t0 = "";
$SP++;' .
((!$flag_parties) ?
((!$boucle->numrows) ? '' : '
$PileNum[$SP] = @spip_num_rows($result);') :
('
$fin_boucle = @spip_num_rows($result);' .
(($boucle->mode_partie == '/') ?
('
$debut_boucle = 1+floor(($fin_boucle * ' .
($boucle->partie - 1) .
' + ' .
($boucle->total_parties - 1) .
')/' .
$boucle->total_parties .
");\n\t" .
'$fin_boucle = floor(($fin_boucle * ' .
$boucle->partie .
' + ' .
($boucle->total_parties - 1) .
')/' .
$boucle->total_parties .
");") :
(($boucle->mode_partie == '+') ?
('
$debut_boucle = ' . $boucle->partie . ';
$fin_boucle -= ' .
$boucle->total_parties) :
('
$debut_boucle = $fin_boucle - ' . $boucle->partie . ';
$fin_boucle -= ' .
($boucle->partie - $boucle->total_parties)) .
';')) . '
$PileNum[$SP] = $fin_boucle - $debut_boucle + 1;')) .
((!$flag_cpt) ? '' : "\n\t\$compteur_boucle = 0;") .
((!$corps) ? "" :
(
((!$lang_select) ? "" : '
$old_lang = $GLOBALS[\'spip_lang\'];') . '
while ($PileRow[$SP] = @spip_fetch_array($result)) {' .
$corps .
"\n\t}" .
((!$lang_select) ? "" : '
$GLOBALS["spip_lang"] = $old_lang;'))) . "
@spip_free_result(\$result);
\$SP--;
return \$t0;"); »
(pour ceux qui en douteraient, il s'agit d'une seule ligne de code ;-))
Aussi pour résumer mon point de vue, on n'est pas là pour faire la
chasse aux picosecondes, si un ensemble de modifs lourdes et
contraignantes ne fait pas gagner minimum 10-20% avec ApacheBench, c'est
pas la peine... (on en a déjà discuté en forum avec Emmanuel)
Enfin il faudra sûrement que quelqu'un relise les commits potentiels et
s'amuse à faire la chasse aux bugs potentiels, fautes de frappe,
oublis...
Amicalement
Antoine.
J'ai posté une nouvelle version du compilateur SPIP sur
http://www.uzine.net/spip_contrib/ecrire/articles.php3?id_article=272
Hola, t'as envie de maintenir ça tout seul ?
Il faut vraiment faire le tri entre les différentes modifs et distinguer
:
- les corrections de bug
- les bonnes idées (inc_kreate (à renommer), fonction pile_index)
- les optimisations locales inutiles (du genre concaténations combinées
: aucun gain visible, code plus compliqué)
- les trucs qui compliquent ou obscurcissent le codeAussi, ce serait sympa (lire : très apprécié) :
- de respecter la convention "une indentation = un caractère de
tabulation"
- la nomenclature aussi c'est pas mal
partout, pourquoi réécrire une fonction en remplaçant par id_a ?)
- de ne pas utiliser de code illisible du genre
......
Aussi pour résumer mon point de vue, on n'est pas là pour faire la
chasse aux picosecondes, si un ensemble de modifs lourdes et
contraignantes ne fait pas gagner minimum 10-20% avec ApacheBench, c'est
pas la peine... (on en a déjà discuté en forum avec Emmanuel)
Il faut aussi faire le tri de toutes tes remarques.
1. J'ai entrepris ce travail sans savoir si je réussirais (car nulle part
était décrit formellement ce qui était fourni en entrée et ce qu'il fallait
délivrer en sortie; en particulier j'ai du jeter à la poubelle une partie de mon code
lorsque la sémantique du include s'est révélée plus complexe que supposée) et si
ce travail serait bien reçu. Pour mon premier envoi, tu en avais laissé tomber
une partie (notamment une correction de bug) et réécrit l'autre, ce qui t'avait pris
un certain nombre de picosecondes. Partant, j'ai trouvé plus prudent de poster une version brute de décoffrage pour voir comment elle serait accueillie. Si elle vous intéresse sur le fond, je suis évidemment partant pour en soigner la forme, que je suis le premier à trouver perfectible.
2. Pourquoi ergoter sur des questions de présentation alors le code que j'ai remplacé était illisible pour des questions de fond ? Avec mon écran 12 pouces, me forcer à "1 indentation = 1 Tab" m'aurait empeché d'avancer aussi vite, et il suffit de qq minutes sous un éditeur pour changer ça. Il faut beaucoup plus de temps pour décortiquer un code qui ne sépare pas programme et donnée, ne mentionne pas ce que les fonctions reçoivent en argument et retournent en résultat, mélange le langage à traduire, son méta-langage et le langage intermédaire, omet de dénoncer les entrées incorrectes, et d'autres que j'oublie. Malgré, je le répète, une forme très perfectible, trouves-tu vraiment que les 7 fichiers que je propose sont plus illisibles que le mastodonte de la 1.6 ?
3. Ne s'intéresser qu'aux optimisations visibles par ApacheBench, c'est réduire un phénomène
à ce qu'en perçoit un instrument d'observation particulier. C'est équivalent à assimiler la
réalité à ce qu'en raconte la télé. ApacheBench a un "hors champ" colossal: la taille des processus. Pour avoir écrit en divers assembleurs natifs et en C des interprètes et des compilateurs, je SAIS que la concaténation de chaines est ce qu'il y a de plus gourmand en mémoire. Partant, écrire:
return A1 . A2 . A3
plutot que (comme j'ai trouvé):
retour = A1; retour .= A2; retour .= A3; return retour;
est plus performant parce que ça évite d'encombrer la mémoire avec le résultat intermédiaire A1.A2
et je trouve ça plus lisible (c'est peut-etre une question d'habitude, mais on peut en dire autant du code non performant). Si ApacheBench ne le voit pas, dommage pour lui (il est peu crédible de toutes façons: il ne donne meme pas 2 fois les memes timings pour un meme jeu de test), mais je veux bien parier que les hébergeurs de SPIP, qui se plaignent régulièrement de la taille des processus PHP, le verront (à moins que PHP soit tellement inadapté à la compilation qu'il ne profite pas de ça; mais alors il faut se poser la question de son utilisation dans cette partie de SPIP car à mesure que celui-ci grossit, PHP ne saura plus l'exécuter dans les temps et espace impartis).
Bref, plutot que de se poser en gardien de principes de présentation dont l'utilité est moins avérée que les qq principes de génie logiciel que j'ai évoqués rapidement, je crois qu'il serait plus utile de trouver comment coordonner au mieux les compétences de chacun (par exemple, et là
je suis bien d'accord avec toi, en précisant les règles de nommage des fichiers, ce qui est beaucoup plus important que celles des paramètres de fonctions). Je veux bien recevoir des leçons sur toute une partie de SPIP que je maitrise mal, mais en ce qui concerne l'écriture d'interprètes et de compilateurs, je crois avoir apporté la preuve que je m'en sors très bien tout seul.
Amicalement,
Emmanuel
et avec ob_start puis ob_get_content, c'est mieux, pareil ou moins
bien ?
parce que si c'est mieux ou pareil en perf, ça serait vachement plus
lisible, puisqu'on pourrait faire du echo et du html en vrac, ce qui
évite de faire du $machin=" du code php qu'on sais plus où ça fini ".
nan ?
À+, Pif
> je SAIS que la concaténation de chaines est ce qu'il y a de plus gourmand
> en mémoire. Partant, écrire:
>
> return A1 . A2 . A3
>
> plutot que (comme j'ai trouvé):
>
> retour = A1; retour .= A2; retour .= A3; return retour;
>
> est plus performant parce que ça évite d'encombrer la mémoire avec le
> résultat intermédiaire A1.A2et avec ob_start puis ob_get_content, c'est mieux, pareil ou moins
bien ?
Pour l'instant SPIP est compatible PHP3
J'ai rien vu qui dise que ob_* soit spécifique php4 dans la doc.
C'est le cas ?
À+, Pif.
Hello,
3. Ne s'intéresser qu'aux optimisations visibles par ApacheBench, c'est
réduire un phénomène
à ce qu'en perçoit un instrument d'observation particulier. C'est
équivalent à assimiler la
réalité à ce qu'en raconte la télé. ApacheBench a un "hors champ"
colossal: la taille des processus. Pour avoir écrit en divers
assembleurs natifs et en C des interprètes et des compilateurs, je
SAIS que la concaténation de chaines est ce qu'il y a de plus gourmand
en mémoire. Partant, écrire:
Mettons donc qu'il y a deux caractéristiques importantes de la
performance d'une page Web dynamique :
- le temps CPU
- la mémoire occupée.
ApacheBench permet de mesurer, sur une machine vide, le temps CPU. Après
divers essais, j'ai trouvé qu'il n'y a à peu près aucune différence
entre les deux types de concaténation que tu évoques.
Pour ce qui est de la mémoire occupée, on a évoqué le sujet en forum. On
peut récupérer la mémoire occupée par un processus grâce au répertoire
/proc (sous Linux). Si je ne me suis pas trompé d'indicateur (champ
VmData dans /proc/<pid>/status), j'ai trouvé que sur ma config, un
processus Apache utilisant PHP prend plusieurs méga-octets de données.
La question est double :
- est-ce que ton optimisation en est une ? tu ne sais pas si
l'interpréteur PHP (qui en fait compile le code PHP en byte-code) ne
fait pas la même chose dans ton dos (en plus sophistiqué peut-être) ; tu
ne sais pas si, au contraire, une concaténation multiple n'est pas
transformée en une série de concaténations utilisant des variables
muettes comme résultats intermédiaires...
- si oui, est-ce que le gain éventuellement apporté par cette
optimisation représente une amélioration substantielle ou marginale par
rapport aux plusieurs méga-octets évoquée plus haut ? j'ai tendance
intuitivement à penser que c'est marginal (un article entier traité par
SPIP fait entre 5 et 50 Ko ; une page HTML générée par SPIP, entre 10 et
100 Ko)
Bref, le seul moyen de peser l'intérêt de cette optimisation (qui ajoute
de la complexité dans le code), c'est d'avoir des mesures.
Si ApacheBench ne
le voit pas, dommage pour lui (il est peu crédible de toutes façons: il
ne donne meme pas 2 fois les memes timings pour un meme jeu de test),
Peu crédible parce qu'il ne donne pas deux fois les mêmes timings pour
le même jeu de test ? Il y a l'environnement système qui, même s'il
représente des variations plutôt faibles, suffit à rendre les résultats
non constants (sans compter SPIP lui-même, qui effectue d'autres
opérations : il faut savoir relancer les tests un certain nombre de fois
pour épuiser notamment les tâches de syndication). Je ne vois pas en
quoi cela rend cette mesure peu crédible... Libre à toi de trouver un
protocole de test plus satisfaisant.
mais je veux bien parier que les hébergeurs de SPIP, qui se plaignent
régulièrement de la taille des processus PHP, le verront
"Régulièrement" ? Je ne sais pas de quoi se plaignent les "hébergeurs
SPIP" (qui en général hébergent beaucoup d'autres choses au point qu'il
est hypocrite de prétendre que c'est un programme particulier qui pose
problème), mais au vu de la différence de facilité (et de coût) entre
augmenter la mémoire et augmenter la puissance processeur, connaissant
aussi la relative lenteur de PHP, j'aurais plutôt tendance à trouver que
les ressources CPU sont plus importantes à ménager.
Du reste, on parle ici de la génération de pages, qui est
statistiquement peu fréquente grâce à l'existence du cache... Il n'y a
donc pas lieu de chercher à gagner des pouillèmes par tous les moyens.
(à moins que
PHP soit tellement inadapté à la compilation qu'il ne profite pas de
ça; mais alors il faut se poser la question de son utilisation dans
cette partie de SPIP car à mesure que celui-ci grossit, PHP ne saura
plus l'exécuter dans les temps et espace impartis).
En fait, SPIP utilise PHP simplement parce que c'est le langage de
programmation Web le plus répandu. Il est hors de question, dans la
distribution principale de SPIP, d'inclure des bouts de code programmés
dans un autre langage (et surtout pas un langage nécessitant une
compilation séparée), car alors beaucoup d'utilisateurs se verront
exclus d'office. PHP n'est pas un langage foudroyant en termes de
performances (euphémisme) mais c'est le seul qui permette une telle
diffusion et un tel accès.
(Voir : http://www.bagley.org/~doug/shootout/
Même Perl est souvent deux à trois fois plus rapide que PHP.)
Amicalement
Antoine.
J'ai rien vu qui dise que ob_* soit spécifique php4 dans la doc.
C'est le cas ?
Ouip
« ob_start
(PHP 4 )
ob_start -- Turn on output buffering »
Amicalement
Antoine.
Ha les vaches, dans la traduction de chez nexen c'est pô marqué 
Bon ... alors, on le jette ou pas php3 
À+, Pif.
> Ouip
> PHP: ob_start - Manual
>
> « ob_start
> (PHP 4 )
Ha les vaches, dans la traduction de chez nexen c'est pô marquéBon ... alors, on le jette ou pas php3
Selon toute vraisemblance, après la 1.7...
(ça ne prouve rien à l'utilité de ob_*, hein)
(à propos de ob_start et ob_get_content qui sont du php4 uniquement):
Pour l'instant SPIP est compatible PHP3
Ces deux fonctions sont présentes dès les premières versions du fichier
inc_surligne.php3 (sic) présent sur le CVS depuis le 19 Mars 2002.
Depuis cette date au moins, SPIP n'est donc pas compatible PHP3.
Dans mon précédent mail, je disais que les 12 cas de php appelé
par les productions du compilateur de squelettes sont à réécrire;
je ne croyais pas si bien dire....
Emmanuel
@ Déesse A. <esj@vertsdesevres.net> :
Ces deux fonctions sont présentes dès les premières versions du fichier
inc_surligne.php3 (sic) présent sur le CVS depuis le 19 Mars 2002.
Depuis cette date au moins, SPIP n'est donc pas compatible PHP3.
Sur php3 le surlignage ne se fait pas ; mais ça ne provoque pas de blocage,
c'est géré proprement...
Sinon, à propos de ton dialogue avec Antoine, personnellement ça ne me
paraît pas plus compliqué de lire du code avec des
"xxxxxxxx"
. "yyyyyyyyyyy"
. "zzzzzzzzzzzzz"
que l'autre truc ; si c'est bien écrit et indenté, c'est pareil...
Ce qui m'ennuierait en revanche serait que le compilateur ajoute encore un
niveau d'abstraction ; je l'ai regardé trop rapidement pour me faire une
idée. (Ca avait l'air lisible, pour ce que j'ai vu - mais je n'ai pas tout
regardé en détail.)
-- Fil
Ces deux fonctions sont présentes dès les premières versions du fichier
inc_surligne.php3 (sic) présent sur le CVS depuis le 19 Mars 2002.
Depuis cette date au moins, SPIP n'est donc pas compatible PHP3.Sur php3 le surlignage ne se fait pas ; mais ça ne provoque pas de blocage,
c'est géré proprement...
ok, mais prendre comme suffixe ".php3" pour un fichier dont on sait qu'il ne
marche que sous php4, c'est pas malin. Et peut-on parler de compatibilité
si certaines fonctionnalités sont manquantes ?
Par ailleurs, j'ai un doute sur la perennité des champs DEBUT_SURLIGNE
et FIN_SURLIGNE: les utiliser statiquement ne me semble pas utile
(et d'ailleurs je n'ai pas vu de squelette le faisant) et le moteur
de recherche semble les ignorer. En outre, ils ne sont pas documentés
(en tout cas le moteur de recherche de la doc ne les connait pas).
Si effectivement ils ne servent pas/plus, c'est 2 appels dynamiques
à PHP d'évacués.
Sinon, à propos de ton dialogue avec Antoine, personnellement ça ne me
paraît pas plus compliqué de lire du code avec des
"xxxxxxxx"
. "yyyyyyyyyyy"
. "zzzzzzzzzzzzz"
que l'autre truc ; si c'est bien écrit et indenté, c'est pareil...
Merci.
C'est comme l'argot et le subjonctif: personne n'a le droit dire
que c'est son style qui est la norme.
Ce qui m'ennuierait en revanche serait que le compilateur ajoute encore un
niveau d'abstraction ; je l'ai regardé trop rapidement pour me faire une
idée. (Ca avait l'air lisible, pour ce que j'ai vu - mais je n'ai pas tout
regardé en détail.)
Au contraire ! Actuellement le compilateur produit du code PHP/mySQL qui
lui-meme produira à l'exécution du PHP, non pas du HTML pur
(car le compilateur lui fait produire des balises "<?php", ce
qu'on voit dans le compilateur par les séquences "<" . "?php" inévitablement
illisibles). Mon souhait est de se passer de ce niveau supplémentaire.
Un squelette 100% HTML+SPIP sera donc compilé en HTML pur et on gagnera
une passe (un niveau si tu veux) d'analyse syntaxique PHP.
Un squelette qui contiendrait des balises "<?" exigerait toujours ce niveau
supplémentaire actuellement systématique, mais l'avantage est que son auteur
serait libre de choisir le langage: PHP bien sur, mais aussi JSP et autres.
Je ne propose donc pas de rajouter un niveau, mais au contraire de le supprimer
quand l'utilisateur n'en a pas besoin, et de le laisser choisir le langage de
ce niveau s'il en a besoin.
Emmanuel
>Sur php3 le surlignage ne se fait pas ; mais ça ne provoque pas de
>blocage, c'est géré proprement...ok, mais prendre comme suffixe ".php3" pour un fichier dont on sait qu'il
ne marche que sous php4, c'est pas malin. Et peut-on parler de
compatibilité si certaines fonctionnalités sont manquantes ?
Moi ça ne me dérange pas, dans ce cas précis.
Par ailleurs, j'ai un doute sur la perennité des champs DEBUT_SURLIGNE
et FIN_SURLIGNE: les utiliser statiquement ne me semble pas utile
(et d'ailleurs je n'ai pas vu de squelette le faisant)
Tu n'as pas vu, mais pourtant ça existe
Là par exemple ;
et le moteur de recherche semble les ignorer.
??
En outre, ils ne sont pas documentés (en tout cas le moteur de recherche
de la doc ne les connait pas).
Oui, c'est un oubli dans la doc
Si effectivement ils ne servent pas/plus, c'est 2 appels dynamiques à PHP
d'évacués.
Désolé, mais c'est très utile quand tu veux vraiment contrôler les zones à
surligner. On peut éventuellement mettre un commentaire "statique" plutôt
qu'un bout de php, par contre, ça ne doit pas être trop dur de récrire
inc_surligne en lui demandant de repérer ces commentaires et de n'agir
qu'entre un "début" et une "fin". La seule différence sera de laisser ces
commentaires dans la page finalement envoyée au client (c'est un peu moins
clean).
-- Fil
Je me suis mal exprimé: le moteur de recherche fait son boulot sans utiliser
les champs DEBUT_SURLIGNE et FIN_SURLIGNE. Du coup, j'aurais aimé voir le
source d'un squelette (pas une URL avec "var_recherche", j'en ai dejà sur
le site des Verts de Sèvres) qui les utilisent, car en l'absence de doc
je n'arrive pas à en saisir l'utilité. En outre, la stratégie actuelle
qui ne surligne que 4 occurrences maxi est tout de meme trompeuse.
Mais je rappelle que ce n'est pas tant ces fonctionnalités là qui
m'intéresse, que la question de savoir comment l'implémenter sans
empiler 2 niveaux de PHP.
Emmanuel
