selon les secteurs, j'ai un code couleur différent, mais toujours la même
mise en page.
bonne idée.
après avoir lu des contributions, j'ai essayé le code suivant dans le
squelette article et à mon grand étonnement ça marche !!!
hé hé !
Des spécialistes pourraient-ils me dire si je risque des lenteurs ou autre
pb avec cette méthode ?
Non, c'est bon, quelques if() ou switch() ne ralentissent absolument pas le
serveur; mais tu aurais pu faire plus lisible, par exemple en groupant toute
la partie "variable" au début :
Parce que l'#ID_SECTEUR est un numéro, pas un texte.
Le problème d'un texte, c'est qu'il peut contenir des caractères qui ont un
sens en php, comme les délimiteurs de fin de chaîne " et ', ou l'appel d'une
variable $toto.
Si vous faites $texte = "#TEXTE" dans un squelette, et que le texte de
l'articele contient le paragraphe ci-dessus, le " va causer une fin de
chaine anticipée, et une erreur de syntaxe.
Si vous mettez $texte = '#TEXTE' à la place, c'est le ' qui va causer une
erreur.
Enfin, si vous utilisez addslashes() et entourez la balise #TEXTE de
guillemets doubles ("#TEXTE"), c'est $toto qui sera interprétée et remplacée
par la valeur de la variable $toto... vide, probablement, mais le but est
d'afficher les caractères $, t, o, t et o.
C'est à ça que sert la syntaxe '[(#TEXTE|texte_script)]'. Avec #ID_SECTEUR,
c'est un simple nombre... donc on n'a pas tous ces problèmes.
ben, #ID_SECTEUR c'est pas du texte c'est juste un entier donc la valeur mise à la place risque pas d'embrouiller les pinceaux de la syntaxe php.
Ayant tout de même beaucoup de mal piger la mixure php et spip, je tente cette description :
Le processus d'interprétation d'un squelette HTML, c'est :
1) SPIP lit le fichier et le transforme :
- remplace chaque #BALISE par sa valeur,
- idem pour les variables passées en paramètre (sauf les variables intitulées var_xxxxxx )
- les boucles sont "interprèdéveloppées" : la base MYSQL est interrogée, et un code HTML est généré en conséquence à la place des divers <éléments> de la boucle.
- le code PHP des appels de filtre est créé et ajouté (mais non exécuté) au fichier généré.
3) tout ça est fourré tel quel dans un cache. Le code PHP (et javascript d'ailleurs) est donc laissé tel quel dans le fichier dans le cache, ainsi que les variables php ou les variables intitulées var_xxxx de la ligne de commande. (ces dernières ne sont pas prise en compte pour la création d'un cache et restent 100% dynamiques)
4) pour l'affichage, le cache est lu (avec les bonnes instanciations des variables var_xxxxx de la ligne de commande) et le code php / java est exécuté sur le site / en local.
En conséquence le code php est exécuté APRES le travail de SPIP et donc il peut y avoir des balises spip dans un code php. Par contre, le code spip ne peut PAS utiliser de variables PHP en dehors des variables normales passées en ligne de commande ...
"SPIP D'ABORD !!"
...
En est il vraiment ainsi ?
PS : pas trouvé doc sur var_xxxxx.
Raphaël Robin wrote:
$secteur = #ID_SECTEUR;
pourquoi y'a pas besoin de |texte_script là ??!
selon les secteurs, j'ai un code couleur différent, mais toujours la
même
mise en page.
bonne idée.
après avoir lu des contributions, j'ai essayé le code suivant dans le
squelette article et à mon grand étonnement ça marche !!!
hé hé !
Des spécialistes pourraient-ils me dire si je risque des lenteurs ou
autre
pb avec cette méthode ?
Non, c'est bon, quelques if() ou switch() ne ralentissent absolument pas
le
serveur; mais tu aurais pu faire plus lisible, par exemple en groupant