PHP|Débutant :: Forums

Bonjour,

J'ai parcouru très recemment les forums sur le sujet ci-dessus par simple curiosité et j'ai été étonné de ce que j'ai pu lire. Soucieux de donner les bons outils et les bonnes habitudes dès le début de l'apprentissage et bien que ce sujet relève tout de même d'une certaine façon de la programmation avancée, je vais essayer ici de séparer le grain de l'ivraie de la manière la plus simple qui soit possible.

Je vous donne d'abord quelques liens que j'ai eu l'occasion de parcourir et qui vont servir de point de départ à mes commentaires.

1) 1er lien
2) 2e lien
3) 3e lien
4) 4e lien

Alors avant de commencer, une mention spéciale pour cet étudiant en Master informatique (dernier lien) qui visiblement ne sait toujours pas résoudre un problème simple seul qu'il n'avait pas appris au préalable (et donc pour lequel on ne lui avait pas fourni de solution), ne savait toujours pas avant d'aller sur le site du zéro faire de l'ajax, et qui s'est débrouillé pour trouver une bible complète de 500 pages sur le javascript sans qu'il n'y ait une seule ligne qui traite ou qui introduise ne serait-ce que les notions rudimentaires de l'Ajax. Un sujet insolite qui méritait d'être souligné.

Alors, beaucoup de choses ont été dites dans ces liens qui sont absolument vraies et qui doivent être retenues et dans toutes circonstances. Les voici dans l'ordre chronologique:
1) Le PHP est un script qui s'exécute du côté serveur.
2) Le Javascript est un script qui s'exécute côté client.
3) Le PHP sera toujours traité avant le code javascript.
4) Une fois la page chargée côté client, le seul moyen de mettre à jour celle-ci sans recharger la page, est de le faire en javascript en utilisant l'Ajax.

Par conséquent à partir de là, le seul contexte possible dans lequel le problème évoqué dans le sujet de ce post peut se poser c'est : pendant le chargement de la page.

Alors dans ces liens, ont a vu des gens qui parlaient d'iframe et d'URL. Je ne cite pas les autres car cela est sans intérêt. Que sont ces techniques? Tout d'abord ce sont des techniques qui sortent un peu du contexte que je viens d'indiquer qui est de traiter le problème du sujet au chargement de la page. Pourquoi un peu? car elles peuvent s'utiliser une fois la page chargée et pendant son chargement.

Avant de continuer, 2 rappels essentiels

1er Rappel
il est essentiel de rappeler le contexte global de développement d'un site : il est 100% objet. Je me permet donc ici de rappeler à toute la communauté de développeurs PHP qu'un serveur PHP est un serveur de type objet, qui n'est donc pas conçu pour gérer des bases de données mais pour gérer les interactions des utilisateurs avec l'applicatif. C'est donc la vocation primaire des frameworks (Zend, Drupal, etc...) et non pas je ne sais quoi d'autre à la mode.

2e Rappel
Le principe fondamental du développement orienté objet est le principe d'encapsulation.Pour ceux qui ne comprennent pas l'Anglais voici un résumé en quelques mots

Bien que cette définition soit quelque peu maladroitement simplifiée et par conséquent représente des inexactitudes pour les puristes, ce qu'il faut retenir: c'est que l'encapsulation signifie que toutes les variables et fonctions (propriétés et méthodes) servant à gérer l'objet et qualifiant l'objet auxquelles elles appartiennent doivent rester la propriété exclusive de l'objet et ne doivent pas être accessibles de l'exterieur sans être contrôlées et gérées par l'objet lui-même.

Conséquence directe (Règle POO) : En POO toute variable/élément appartenant à un objet ne peut être et ne doit être définie en dehors de l'objet lui-même.

Important
Dans cet environnement l'applicatif gère l'interaction et le comportement des objets les uns par rapport aux autres. L'applicatif représente donc l'environnement global pour les objets.

Dans un modèle MVC standard dans la programmation client-serveur WEB, la vue représente ce qui s'affiche à l'écran. Ainsi chaque espace distinct de l'affichage doit être conçu comme un module autonome distinct des autres. (news, menu, espace connexion, publicité, etc...). Ce type de modèle apparaissant un peu flou dans un contexte php, l'est beaucoup moins par exemple dans un environnement Sharepoint avec les fameux webpart fortements typés dans ce sens et respectant beaucoup plus les règles structurelles de la programmation OO.

Ainsi tout le contenu de l'information affiché sur votre écran doit normalement se trouver et être accessible via sa propre classe PHP sur le serveur et maintenu en cache (en général en session et dans le DOM par le serveur tiers (PHP) et le client respectivement).

Maintenant que le contexte "normal" de travail est rappelé et bien clair pour tout le monde, comment résoudre notre problème et qu'en est-il des deux techniques précédemment abordées que sont l'URL et l'Iframe?

l'URL
l'URL fait partie intégrante de l'espace global de l'applicatif et géré par un objet ou ensemble d'objets PHP de l'applicatif nommé(s) Front Controller/Global Front Controller (Controleur frontal). Par conséquent, stocker temporairement une variable au niveau applicatif pour transmettre une donnée objet à un autre objet, est une mauvaise pratique, bien qu'elle soit bien pratique. Elle est en effet couramment utilisée et préférée autant que possible car cet espace est peu voire pas conflictuel pour l'applicatif car externe au serveur php (dédié à l'utilisateur côté client).

l'Iframe
Utiliser un iframe pour cette tâche est complétement et définitivement une mauvaise pratique car cela revient à utiliser un objet comme espace global pour les autres objets, bref à créer une application dans l'application, ce qui est fortement conflictuel, pas propre du tout, difficile à maintenir, bref, cette solution est une solution de facilité quoi qui peut devenir vite complexe et ingérable si l'on aborde l'aspect compatibilité cross browser et portabilité DTD. Solution à proscrire!!!!

Au travers de tout ce que l'on vient de dire il en ressort une chose essentielle : Notre problème de récupérer une variable Js dans PHP est un faux problème qui provient du fait que le problème ou la question posée n'est pas considérée comme elle doit l'être car la variable js est forcément une donnée qui a été fournie initialement par PHP et donc qui sera toujours disponible au niveau de PHP dans le contexte qui nous interesse. (L'autre étant le DOM, mais là on retombe dans du classique).

En conclusion quand ce problème se pose, cela signifie que l'on sera toujours dans un contexte de chargement de page et avec un problème de récupération de variable PHP dans Js.

_________________________________________________________

Illustration et résolution du problème par l'exemple.

Imaginons que l'on construise un menu dynamique applicatif en Js. Au niveau contexte cela signifie que l'on est forcément en mode connecté, avec un id utilisateur et des droits particuliers sur l'applicatif et donc un menu spécifique. Comme on développe en objet, le menu est donc un objet de type vue représenté par un fichier dédié de type js. Tout le code qui gère l'affichage de ce module est donc strictement inclus dans ce fichier js, et alimenté par une requête spécifique et optimisée sur le SGBDR. Le contrôleur situé au niveau de PHP doit donc passer à js les informations spécifiques de l'utilisateur issues de la requête et ce dynamiquement au chargement du fichier, puisque l'affichage initial de la page se fait d'une manière synchrone.

Comment faire alors?

Il suffit pour cela de changer l'extension de notre fichier js en php. S'il vous est naturel dans un fichier PHP d'écrire du code html en dehors de balises <?php ?>, sachez que cela fonctionne pareil avec du code js mais exclusivement js, comme pour le html.
Comment déclarer alors votre fichier js devenu php dans votre page php principale ?

Et le tour est joué. Mais les contraintes techniques ne se limitent pas qu'à cela. En effet cette insertion ne fonctionne pas au même titre qu'un include. Le navigateur considère en effet que seul du contenu js sera déclaré malgré le fait qu'il soit interprété par le serveur PHP. La conséquence à cela c'est que tout le code PHP en amont de cette balise <script> ne sera pas disponible dans le fichier module_menu_js.php
Comment alors récupérer l'id utilisateur stocké par exemple dans la classe de gestion des utilisateurs sur le serveur PHP qui a été mis en cache par sérialisation en session? (exemple de contexte).
1) Comme le code js sera considéré comme une sortie, si un appel aux variables de session PHP doit être fait, il faudra réécrire avant tout code js un <?php session_start()?>
2) Faudra refaire les includes nécessaires à la bonne déserialisation de la classe gérant cet id, même si cela a déjà été fait dans le fichier principal index.php
3) seuls les noms de variables php doivent être passés au code js. Ainsi les opérations et les calculs doivent être fait préalablement à toute affectation du côté js.

Pour ceux qui pensent à ce stade que la question posée n'a pas encore été résolue (peut-être notre étudiant en Master info) je les invite à reconsidérer la formulation de leur problème précisément, et pour les irréductibles, à penser sérieusement à la restructuration de leur code.

Merci par avance pour vos retours et commentaires.

Cordialement,

Jc.

Dernière modification par Jc (19-06-2012 02:27:59)