Salut,
J'ai dû ajouter un: "global $HTTP_USER_AGENT", vu que je n'arrivais
plus à le récupérer d'aucune autre manière.
Oui. Ca marche n'est-ce pas ? D'ailleurs c'est exactement ce que j'avais écrit
dans mon précédent mail : "Du coup, tous les includes (à part inc.php3
et inc_version.php3) doivent faire gaffe à appeler les variables globales
par $GLOBALS[]." $GLOBALS['HTTP_USER_AGENT'], donc, plutôt que directement
$HTTP_USER_AGENT. Tu es habitué à le faire dans les fonctions, pourquoi ça
t'embête en-dehors ?
Du coup, est-ce que quelqu'un pourrait m'expliquer clairement et
simplement à quoi servent toutes ces nouvelles trouvailles auxquelles
je ne bite rien du tout, sauf une chose: je pige de moins en moins
comment le bestiau est programmé et tout ce que j'entreprends devient
excessivement compliqué.
Au contraire, c'est fait pour rendre des choses intéressantes plus
simples à programmer (sans quoi un système d'onglets, ou tout autre
système nécessitant des variables persistantes, n'existera jamais
de façon utilisable sauf à stocker des dizaines de cookies sur l'ordi
de l'utilisateur. cf. le système actuel de dépliage de "blocks", qui
ne se souvient pas des réglages quand on clique sur un lien, ce qui
est peu pratique).
D'autre part, passer des "variables qui se baladent" est indispensable
pour faire une identification sans htaccess ni authentification PHP,
ce qu'il faudra bien se résoudre à entreprendre puisque c'est là le
problème de majeur de compatibilité et d'installation SPIP (ainsi que
l'objet de la moitié des docs et FAQs de la partie "premiers pas", et
d'une bonne part des questions de la liste SPIP). Quant à l'utilisation
obligatoire de cookies, ça m'embête parce que beaucoup d'utilisateurs
se méfient, parce que dans certains cas il faut les acceper au cas par cas,
et parce que les nouveaux navigateurs (Mozilla, IE 6) commencent à avoir
des réglages très restrictifs (genre il faut une "charte de vie privée" sur
le site pour le navigateur accepte le cookie).
Bien comprendre que ce système de liens gère automatiquement le passage
"silencieux" de variables, mais aussi les urlencode pour les URLs, les
htmlspecialchars pour les formulaires, etc. Ce qui permet de se délivrer
de pas mal de petits soucis, plus ou moins gros.
Un petit tour simple :
- d'abord les raccourcis :
// renvoie automatiquement le href=".." correspondant au lien filé en paramètre
echo newLinkHref('machin.php3?variable=truc&etc=2');
// renvoie simplement l'URL (sans les guillemets et le href autour donc)
echo newLinkUrl('bidule.php3');
// renvoie la valeur courante de la variable temporaire, dont le nom est une chaîne quelconque
$onglet_courant = getTmpVar('onglet config_precise');
- pour des besoins plus complexes, utiliser la classe elle-même :
Pour rester sur la page courante en modifiant une variable :
// crée un lien dans la variable $link à partir de l'URL de la page courante
$link = new Link;
// ajoute la variable modifier_site avec la valeur oui
$link->addVar('modifier_site', 'oui');
Pour passer à une autre page
$link = new Link('sites.php3?id_syndic=$id_syndic');
// éventuellement, ajouter des variables à la main
$link->addVar('titre', $titre);
Pour afficher le lien
// dans un bête href
echo $link->getHref();
// dans un formulaire : cela affiche le <form> suivi des entrées "hidden" correspondantes
echo $link->getForm('POST'); // on aurait pu mettre 'GET'
// ajouter éventuellement des champs à remplir
echo "<input type='text' name='url_site' value='http://'>";
// ajouter le submit et fermer le <form>
echo "<input type='submit' name='submit' value='Valider'>";
echo "</form>";
Il y a d'autres fonctions mais je ne détaille pas ici. Il n'est pas
interdit de consulter le code déjà écrit (édition des sites syndiqués,
par exemple, ou la fonction afficher_tranches() dans inc.php3), qui
ne doit pas être très dur à comprendre si on se donne la peine.
Evidemment, il y a sûrement un temps d'apprentissage. Aussi, pour
éviter d'apprendre à utiliser les fonctions, on peut mettre tout
le code au niveau global, en faisant des copier/coller si besoin
est. Au bout d'un moment, on ne gagne plus vraiment de temps en
faisant ainsi, et on n'avance plus qu'à coup de bidouilles.
Il y a sûrement aussi des faiblesses, auxquelles il est probablement
possible de remédier....
Quant au fait que ce soit une classe, c'est la seule façon propre
de faire pour ce genre de choses. Les classes et les objets, c'est
franchement pas dur à comprendre. Un objet, c'est comme une structure
dans un langage genre Pascal, mais à laquelle sont attachées des fonctions
en plus des variables. Point de vue utilisation, c'est bénin. Suffit
de penser à la flèche pour accéder aux champs et aux fonctions internes.
Exemples: je veux bien ne plus utiliser de
variables globales, mais faut m'expliquer en mots simples ce que je
peux faire à la place
Ce n'est pas qu'il ne faut pas utiliser de variables globales, c'est
qu'il ne faut pas s'étonner de ne plus les trouver accessibles sans
utiliser $GLOBALS[...] ou le mot-clé global. Du reste, le code au niveau
global est à éviter, pour des raisons de maintenabilité du code (c'est
toujours plus sûr de transporter une fonction d'un fichier à un autre,
que de transporter un bout de code exécuté directement lors de l'inclusion).
Il vaut mieux faire des fonctions, quitte à appeler ces fonctions
automatiquement lors de l'include (cf. les modifs que j'ai faites
dans inc_auth). Du reste, utiliser des variables de fonction permet
d'éviter les conflits éventuels entre variables globales (souvenirs
récents et mises en garde anciennes :-)).
J'ai été obligé d'introduire le include_local() pour résoudre le bug
récent des signatures de pétitions en PHP3, et tout autre bug lié
à l'inclusion, à l'intérieur d'une fonction, d'un include faisant
un return. Il était donc intéressant de généraliser le include_local(),
pour éviter au maximum d'autres ennuis de ce genre (sachant que pour
faire des inclusions de squelettes, il faudra passer une part du code
d'inc_public en fonctions, et que dans ces fonctions il y aura des
include, donc des include_local() pour éviter les pbs avec PHP3).
Je vous signale que l'effet immédiat de ces modifs est de me fermer
purement et simplement la porte de SPIP au nez.
Tout de suite les grands mots :-)) Non sérieux, une fois l'adaptation
faite, ce sera beaucoup plus facile au contraire. C'est très pratique de
pouvoir définir des variables persistentes sans avoir à chaque fois à se
palucher à la main le bidule qui va les gérer (cookies, etc.). Une fois
que la fonctionnalité est là, elle sera très intéressante à utiliser
pour rendre l'interface plus pratique (notamment, donc, pour les onglets
et les "blocks"). C'est très pratique aussi de ne pas se farcir les urlencode
et autres htmlspecialchars à la main. Surtout, le jour où on veut modifier
le comportement des liens, il y aura juste un endroit du code à modifier,
pas tout le HTML codé à la main dans l'espace privé comme c'est le cas
actuellement. C'est la même motivation que pour les fonctions du genre
debut_boite_info()....
a+
Antoine.
