PHP|Débutant :: Forums

Advertisement

Besoin d'aide ? N'hésitez pas, mais respectez les règles

Vous n'êtes pas identifié(e).

#1 18-06-2012 05:29:09

Jc
Membre
Lieu : Zillisheim - Alsace
Inscription : 15-04-2010
Messages : 1 629
Site Web

Prog avancée: Récupérer une variable Js dans PHP.

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

wiki encapsulation objet a écrit :

General definition
In general, encapsulation is one of the 4 fundamentals of OOP (object-oriented programming). Encapsulation is to hide the variables or something inside a class, preventing unauthorized parties to use. So the public methods like getter and setter access it and the other classes call these methods for accessing.

traduction wiki a écrit :

Définition générale
De manière générale, l'encapsulation représente l'un des 4 fondamentaux de la programmation orientée objet. L'encapsulation sert à cacher les variables ou quelque chose dans une classe, prévenant ainsi des personnes non autorisées à les utiliser. Ainsi les les méthodes publiques comme get() et set() servent à y accéder et les autres classes appelent ces méthodes pour y accéder également.

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 ?


// par exemple dans le body de votre page index.php (il s'agit d'un module objet de type vue)
<script type="text/javascript" src="module_menu_js.php"></script>
 

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)


POO PHP+Ajax en MVC avec PDO et Bases de données épaisses  : What else?

Hors ligne

#2 18-06-2012 06:36:00

Maljuna Kris
Infantimigulo
Lieu : Douarnenez 29100 Breizh Izel
Inscription : 08-05-2009
Messages : 2 453
Site Web

Re : Prog avancée: Récupérer une variable Js dans PHP.

Saluton,

Tout d'abord, avant tout et essentiellement un grand MERCI à Jc pour ce pavé structuré et structurant.

Je commencerai par rendre justice à Ollivier Hondermarck, auteur du Guide Complet du Javascript (2006), dont le chapitre 14 (pp 413 à 440)  Ajax et Web 2.0 se décline en trois § majeurs
14.1 La révolution Ajax
14.2 Le concept Web 2.0
14.3 Cas pratique : contrôle des pseudos avec Ajax.
Ce correctif ne fait qu'accabler davantage cunegonde, l'étudiante en Master déjà bien allumée par Jc, j'en ai conscience, mais le livre, qui n'est pas irréprochable par ailleurs, était l'objet, sur ce point, d'une critique infondée.

Je réagis bien sûr à cette importante (en volume et en qualité de contenu) contribution de Jc tout d'abord sur la forme.

Outre les quelques corrections orthographiques, syntaxiques et grammaticales ou de frappe que j'y ai traditionnellement apportées (c'est un TOC chez moi), je dirais que l'environnement de design de nos forums se prêtent assez mal à mettre en valeur ce genre d'exercice. Il faut d'autant plus féliciter Jc pour l'effort louable qu'il y a déployé.

Sur le fond maintenant, force est de constater que tout cela va passer au-dessus de la tête de la majeure partie de notre public, hélas.

Et là, on touche au paradoxal, quand on sait que nombre de professionnels ou prétendus tels n'ont toujours pas intégré l'approche objets, encore considérée comme trop ardue pour les débutants par une majorité d'enseignants (cf, par exemple, l'échange que nous avons eu récemment avec un représentant d'un organisme de formation), n'est-ce pas se couper, a priori, de notre "public" que de l'interpeller par cette façade ?

A la décharge de Jc, je dois reconnaître que PHP, qui envisage, dans un proche avenir, de ne plus rendre possible l'accès aux SGBD sinon par l'intermédiaire de PDO, semble indiquer clairement dans quelle direction doivent porter nos efforts.

Les patrons de conception (design patterns) qui font florilège, même s'ils n'induisent pas forcément une approche objet, s'y trouvent quand même, eux aussi, plus à l'aise.

Nous sommes donc à la croisée des chemins, ce qui a fait, en son temps, le succès de PHP, de Javascript et d'HTML est ce qui aujourd'hui en constitue la faiblesse.

Le temps n'est plus au laxisme et au grand foutoir, le temps est à la démarche structurée et cohérente du fait même de la synergie des supports qu'illustre si bien Ajax, mais aussi CSS voire XML.

Reste que nous sommes, ici, un site éponyme dédié en priorité aux débutants, la pédagogie se doit donc d'y être mieux servie que par des posts, aussi remarquables soient-ils, distillés au fil du temps, sans liaison entre eux, sans cohérence globale.

Le travail de Jc a le grand mérite de lancer des bouteilles à l'eau plutôt que d'attendre le grand soir de la V2 du site, éternelle arlésienne, mais, surtout, il met, les quelques-un(e)s plus ou moins fondateurs de ce site face à nos responsabilités au regard de cette désormais indispensable mise à jour qui requiert a minima un dépoussiérage et quelques compléments, dans l'idéal une refonte totale de nos tutoriels.

Bon, on commence quand, où, comment et qui y fait quoi, les amis ?

Amike, MoKo.


Gloire à qui n'ayant pas d'idéal sacro-saint,
Se borne à ne pas trop emmerder ses voisins. G. Brassens Don Juan 1976.
Avĉjo MoKo kantas
La chaîne YouTube MoKo Papy

Hors ligne

#3 18-06-2012 12:01:44

Jc
Membre
Lieu : Zillisheim - Alsace
Inscription : 15-04-2010
Messages : 1 629
Site Web

Re : Prog avancée: Récupérer une variable Js dans PHP.

Merci MK pour ton retour smile

Jc.

Dernière modification par Jc (18-06-2012 20:00:25)


POO PHP+Ajax en MVC avec PDO et Bases de données épaisses  : What else?

Hors ligne

#4 19-06-2012 01:32:53

Jc
Membre
Lieu : Zillisheim - Alsace
Inscription : 15-04-2010
Messages : 1 629
Site Web

Re : Prog avancée: Récupérer une variable Js dans PHP.

Pour les tutos j'apporte une modeste contribution avec ces suggestions

CSS3.0
- Les feuilles de styles
- Feuilles de style vs inline
- Les classes
- Les pseudo-classes.
- Introduction aux fonctionnalités avancées.

HTML5
-Canvas
-SVG
-Medias
-References

Javascript
-LocalStorage/SessionStorage
-Ajax
-Portées en javascript
-POO
-Jquery

- Introduction architecture applicative

PHP
-Les simples et doubles quotes
-Le typage des variables
-Les sessions
-La Serialisation/déserialisation
-Les Try/Catch
-Error_reporting() + Exceptions + gestionnaire erreur personnalisé.
-Presentation POO
-Les portées en PHP POO
-L'héritage
-Les interfaces
-Présentation des design patterns
-Le Garbage Collector
-Ex le Singleton / Front Controller de base.
-Ex Mise en cache d'une classe par serialisation. Idem avec le cas particulier du Singleton (si c'est possible).

Pour l'essentiel. Ensuite vous pourriez raffraichir l'existant

Si vous voulez reprendre mes posts aucun souci (en quote dans la mesure du possible merci wink )

Cordialement,

Jc

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


POO PHP+Ajax en MVC avec PDO et Bases de données épaisses  : What else?

Hors ligne

#5 19-06-2012 10:43:03

Maljuna Kris
Infantimigulo
Lieu : Douarnenez 29100 Breizh Izel
Inscription : 08-05-2009
Messages : 2 453
Site Web

Re : Prog avancée: Récupérer une variable Js dans PHP.

Comme je le disais, les objectifs, voire les avantages, de la POO, pour la majeure partie de notre "clientèle" de débutants sont peu motivants.
La portabilité, la ré-utilisabilité voire la segmentation du code et un de ses corollaires, l'encapsulation, peu leur chaut.
En effet, bon nombre sont débutants et en resteront là, c'est une part de l'ambigüité du terme débutant. Un débutant peut être un pro en devenir ou quelqu'un qui a ponctuellement besoin de faire un "truc" en PHP.
Ce dernier est peu réceptif aux arguments qui concernent par contre immanquablement les équipes de développement.
Pour le développeur indépendant et occasionnel les seuls véritables arguments concernent la maintenabilité et l'évitement des effets de bord.

Autre écueil, la variabilité de la POO avec PHP, notamment entre les versions 4 et 5.

Je suis retourné sur l'ancien site phpDébutant et j'ai découvert que les billets de Fred avaient disparu. Dommage, ces contributions concises, pertinentes et d'approche originale me semblaient un vrai plus pour nos tutoriels.
J'ai relu aussi la partie afférente à la POO et, s'il m'en était resté, je me serais arraché quelques touffes de cheveux.
Donc, quand tu parles de rafraichissement des tutos, c'est vraiment un euphémisme.

En comparaison de ce que propose de nos jours un site concurrent comme celui du Zéro, nous faisons vraiment ringard.

Le mieux étant souvent l'ennemi du bien, il nous faut cependant prendre garde à ne pas nous couper de notre public cible, les débutants.

Ce sera la gageure essentielle de la refonte de ce site.


Gloire à qui n'ayant pas d'idéal sacro-saint,
Se borne à ne pas trop emmerder ses voisins. G. Brassens Don Juan 1976.
Avĉjo MoKo kantas
La chaîne YouTube MoKo Papy

Hors ligne

#6 19-06-2012 22:49:54

Jc
Membre
Lieu : Zillisheim - Alsace
Inscription : 15-04-2010
Messages : 1 629
Site Web

Re : Prog avancée: Récupérer une variable Js dans PHP.

Bonjour,

Merci Mk pour ton analyse fort interressante. Quelques retours sur tes propos si tu veux bien.
- Il est difficile de parler de POO avec PHP4 qui ne le permettait pas vraiment. La POO a commencée véritablement et a été rendue possible avec PHP5 en ce qui concerne PHP.
- A propos du site

J'ai toujours considéré que PHP débutant était un site dédié aux programmateurs débutants avec pour vocation de les accompagner dans cet apprentissage et leur donner les clés et les outils pour bien démarrer et progresser. Si ce n'est pas réellement le cas, je pense que le titre du site induit en erreur fortement. De plus, je ne pense pas et/ou je ne suis pas convaincu que l'on puisse appeler un débutant PHP une personne que l'on peut rencontrer sur tous les forums du genre, qui ne sait pas développer, qui n'a pas l'intention d'apprendre plus que ça la programmation, et qui compte sur l'entraide communautaire pour faire touner son site et/ou l'améliorer. Quant au besoin ponctuel, acheter une heure à 40€ à un professionnel ca peut faire gagner du temps et beaucoup plus d'argent à un indépendant que de tourner pendant une semaine sur nos forum pour ne pas payer 1 Euro.

Ensuite la question des objets: Dans toutes les notions que tout le monde manipule même en ne faisant que du procédural, tout n'est qu'objet : CSS3, DOM, HTML, etc... Et contrairement a ce que l'on pourrait penser, il est beaucoup plus facile d'apprendre à programmer en commencant par la POO que par du procédural, ne serait-ce que par l'absence structurelle et structurante du procédural. La POO à plus de dix ans déjà elle est partout et c'est pas plus long à écrire bien au contraire. Je pense sincérement que ceux qui disent que c'est difficile à enseigner à un débutant, ce sont les mêmes qui ne maîtrisent pas ou que très peu le sujet ou qu'alors ils ne sont pas du tout à l'aise avec. Je dirais à ces mêmes personnes qu'il arrive un moment ou faut arrêter de prendre les gens pour ce qu'ils ne sont pas. Une dernière réflexion sur ce sujet: Combien de fois sur ce forum tu as écris en réponse à un internaute la fameuse phrase de boileau? C'est très caractérisque des problèmes des débutants. Ils ne sont pas structurés, choses qui sont cadrées dès le départ avec la POO et qui les oblige à penser les choses d'une manière structurée et cohérente. Ainsi beaucoup d'entre eux sont capables de résoudre leur propre problèmes, mais ne le peuvent à cause de cela. Peut-être que certains y voient une poule aux oeufs d'or à préserver dans le milieu de la formation qui sait...

Ensuite ne mettre du vrai contenu didactique et concret que dans des ouvrages payant, je ne pense pas que cela doive s'appliquer pour un site comme celui-ci et que c'est justement sur ce genre de choses qu'il devrait faire la différence / se caractériser. Cela contriburait également à réhausser le niveau général de la communauté et obligerait aussi les pros à être plus qualifiés encore et à faire de la qualité en toutes circonstances. Tirer les gens vers le bas ne m'a jamais motivé, et si ce site devait prendre une telle orientation je préfererais partir de suite.

Je ne pense pas que les pros qui animent un forum comme developpez.com y participent pour répéter 10 fois comment utiliser les simples ou doubles quotes en PHP et pourtant c'est là que les programmeurs débutants préférent aller majoritairement, alors que cela devrait être l'étape suivante de leur apprentissage. Ceci n'arrive pas par hasard, c'est que personne ne le fait ailleurs et un site comme phpdebutants n'a pas forcément "la clientèle" qu'il devrait toujours avoir.

Voilà en gros comment je vois les choses.

++

Jc

Dernière modification par Jc (19-06-2012 23:14:21)


POO PHP+Ajax en MVC avec PDO et Bases de données épaisses  : What else?

Hors ligne

Pied de page des forums