blabla@php | faq et bonnes pratiques page 1

blabla@php | faq et bonnes pratiques page 1 - Divers - Programmation

Marsh Posté le 26-08-2007 à 03:18:43    

http://hfr-rehost.net/www.nextgeneration.fr/docs/hfr/phphfr.png
 
Pour éviter de répondre sans cesse aux memes questions, j'invite les nouveaux membres du forum à lire ce topic avant de poster une demande d'aide dans la catégorie php.
 
Prérequis et mises au point
 
    Le forum dispose d'une fonction "rechercher", c'est une raison suffisante pour l'utiliser.
    Comme le reste du forum prog, la cat' php n'est pas l'endroit approprié pour recruter, ni proposer ses services. Le forum Emploi et Etudes est là pour ca.
    Il est parfaitement inutile de créer un topic pour demander un script, de l'aide sur phpBB.
 
A] Faq générale
 
    I)  Php, c'est quoi ?
    II)  Qu'est-ce qu'il me faut pour développer en php ?
 
B] Faq technique: le langage, les erreurs classiques, les remèdes
 
    I)  Headers already sent
    II)  Parse error in... leFichierPhp.php on line xxx
    III) Warning: mysql_fetch_xxx(): supplied argument is not a valid MySQL result resource in...  leFichierPhp.php on line xxx
    IV)  Mon code s'affiche dans le navigateur au lieu d'etre interpreté
 
C] Bonnes pratiques
 
    I) Coder avec la configuration la plus restrictive possible
    II) Separer les couches
 
===============
A] Faq générale
===============
 
I) Php, c'est quoi ?

Citation :

Php, c'est un langage de script coté serveur, qui permet de rendre des pages web dynamiques. Php s'utilise aussi en mode CLI, en ligne de commande ( lancer un traitement lourd par une requete HTTP alors qu'on dispose d'un accès SSH sur le serveur relève de la connerie pure et simple ).
Certains disent que php est une incarnation de satan, un langage avec plus de défauts que d'avantages, d'autres ne veulent entendre parler de rien d'autre, ce débat n'a pas sa place ici.  
 
Php, on l'aime ou on le quitte [:sarko]
 
Lire la définition de Php dans Wikipedia


 
II) Qu'est-ce qu'il me faut pour développer en php ?

Citation :

Pour écrire du Php, théoriquement un simple notepad suffit ( comme pour la majorité des langages d'ailleurs ). Mais bon, depuis que Dieu a inventé la coloration syntaxique, faut pas s'en priver.
 
Sous windows, Notepad++ est un outil idéal, coloration multilangages, editeur multi-fichiers avec onglets, macros... Il ne lui manque en fait que le support des outils de versionning et un client ftp intégré.
 
Télécharger Notepad++
 
Sous mac, Textmate fonctionne très bien, jpeux pas en dire plus, si un macqeux veut donner des précisions, qu'il fasse signe.
 
Télécharger Textmate ( version d'eval 30j )
 
Sous linux, Emacs ou Vi, mais en général les gens sous linux sont barbus et n'ont pas besoin qu'on leur conseille un éditeur :o
 
Il vous faut aussi un serveur web, un tutoriel écrit par drasche se trouve ici:
http://forum.hardware.fr/hfr/Progr [...] 2943_1.htm


masklinn a écrit :

* Pour les éditeurs sous nux, il y a Qanta si je ne me trompe pas. Tout le monde n'utilise pas VI ou Emacs ;)
 
(moi chuis pas sous nux, mais j'utilise Emacs sous Windows et sous OSX :o :o :o)


 
===============
B] Faq technique: le langage, les erreurs classiques, les remèdes
===============
 
I) Headers already sent

Citation :

Warning: Cannot modify header information - headers already sent by (output started at  
chemin/physique/du/script1.php) in chemin/physique/du/script2.php on line XXX )
 
Question trop souvent posée sur le forum, alors qu'il suffit de lire le message d'erreur pour comprendre précisément ce qui se passe:
 
Les fonctions header() et session_start() doivent impérativement etre appelées avant que votre script n'envoie un seul octet vers le navigateur. La raison est assez triviale, un en-tete précède le contenu, si vous envoyez du contenu, l'en-tete par défaut est envoyé.
 
Pour debugger, il faut lire le message d'erreur: ici l'appel à session_start() ( ou header() ) se fait dans le fichier chemin/physique/du/script2.php alors que le script a déja commencé à envoyer des données dans chemin/physique/du/script1.php à la ligne XXX.
 
Il faut vérifier egalement tous les fichiers que vous include()z, la moindre ligne vierge avant <?php sera envoyée au navigateur et vous empechera de changer votre en-tete.
Une autre source potentielle de soucis, si vous faites des traitements ( en particulier des requetes sql ) avant d'envoyer vos headers, la moindre erreur ou warning générée par votre code empechera header() ( ou session_start() ) de fonctionner.


masklinn a écrit :

Pour Headers Already Sent, il y a aussi le problème du BOM UTF-8 qui, non reconnu par le parseur PHP, est envoyé au serveur web quand il est présent :/


 
II) Parse error in... leFichierPhp.php on line xxx

Citation :

Si vous obtennez ce genre d'erreurs, pensez en premier à relire le point A) II). Il vous faut impérativement un éditeur à coloration syntaxique pour éviter les erreurs les plus classiques. En effet Dieu a inventé la coloration syntaxique et il serait triste de s'en passer.
 
Et oui ce genre d'erreur vient, la plupart du temps, de fautes de frappe dans le code que vous avez saisis. Ces erreurs sont facilement repérabales à l'aide d'un bon EDI (Environnement de développement intégré).
 
Si l'erreur persiste, pensez à vérifier à la ligne précédente!
Par exemple, une erreur à lé ligne 26 peut venir d'un ; oublié à la ligne 25!


 
III) Warning: mysql_fetch_xxx(): supplied argument is not a valid MySQL result resource in...  leFichierPhp.php on line xxx

Citation :

Ceci n'est pas seulement valable pour MySQL. Mais comme c'est certainement le plus répendu chez les débutants, nous attaquerons par là!
 
Lorsque vous rencontrez ce genre d'erreur, et de manière plus générale, lorsqu'une requête ne change rien à votre base de données pensez à faire appel à la fonction mysql_error() juste après un appel à mysql_query(). Cette fonction vous en dit généralement plus sur l'erreur que vous avez comis lors de la saisie de votre requête en retournant une chaîne décrivant l'erreur en question.
 
Vous pouvez également tester votre requête dans un système d'aide à la gestion de votre base de donnée tel que phpMyAdmin dans lequel vous pouvez saisir directement votre requête et obtennir moultes informations sur les problèmes survenus lors de l'exécution de celle-ci.


 
IV) Mon code s'affiche dans le navigateur au lieu d'etre interpreté

Citation :

Premier travail, copier/coller le script suivant dans un nouveau fichier, qu'on nommera affectueusement test.php:

Code :
  1. <?php
  2.    phpinfo();
  3. ?>


 
Le but est de procéder par élimination pour trouver le problème rapidement.
Mettez ce fichier à la racine de votre htdocs et ouvrez http://127.0.0.1/test.php dans votre navigateur. Si vous voyez le contenu du fichier, votre installation de Php s'est mal déroulée, Apache ne demande pas à Php d'interpréter le fichier avant de le servir. Vérifiez votre httpd.conf, notemment la ligne de l'extention php doit etre décommentée.
 
Si le fichier s'exécute normalement, un tableau apparait, donnant l'etat de la configuration de Php et la liste des modules actifs.
Dans ce cas, l'erreur est certainement dans votre code, les deux sources les plus fréquentes étant l'utilisation de shorttags alors que le serveur ne le permet pas, ou du code php dans un fichier portant l'extention htm.


 
===============
C] Bonnes pratiques
===============
 
I) Coder avec la configuration la plus restrictive possible

Citation :

En cours de rédaction


 
II) Séparer les couches

Citation :

Quand on commence le php, on a vite tendance a faire du code bordélique, des requetes sql suivis d'un echo(), faire des copier/coller à gogo au lieu de définir des fonctions...
 
Quand il s'agit de faire un test vite-fait, passe encore :o
 
Lorsque vos scripts ont pour vocation d'etre exploités sur un site web, il faut revoir la facon dont on organise son appli.
 
Le minimum syndical, c'est de créer les fichiers suivants:
 
- config.php

Infos de connexion à la base de données, constantes utilisées dans tout le site.


- header.php

En-tete du site ( rien à voir avec la fonction du meme nom ), typiquement, doctype html, metas, logo, menu de navigation...


- footer.php

Pied de page, code de stats, etc


 
L'étape d'après, c'est l'utilisation d'un système de templates ( php natif ou search/replace ).
Il en existe plusieurs, le plus simple etant phpLib ( utilisé par phpBB ), un des plus complets etant Smary.
 
L'étape encore après, et la, c'est tout de suite moins drole, est de construire son site sur une architecture MVC.
Un topic de FlorentG explique le concept, propose des approches, il parait qu'on peut meme y lire des prises de tete entre membres du forum [:cupra] : Model View Controller (MVC) - Architecture des applications PHP

Message cité 1 fois
Message édité par Harkonnen le 15-05-2008 à 20:13:16
Reply

Marsh Posté le 26-08-2007 à 03:18:43   

Reply

Marsh Posté le 26-08-2007 à 03:43:56    

Depuis le temps que je l'attendais celle-la.
Bon, je me permet un p'tit reserved aussi pour y contribuer.

 

[edit]
Allez on attaque :

 

Les erreurs courantes :

 

parse error in... leFichierPhp.php on line xxx
Si vous obtennez ce genre d'erreurs, pensez en premier à relire le point A) II). Il vous faut impérativement un éditeur à coloration syntaxique pour éviter les erreurs les plus classiques. En effet Dieu a inventé la coloration syntaxique et il serait triste de s'en passer.

 

Et oui ce genre d'erreur vient, la plupart du temps, de fautes de frappe dans le code que vous avez saisis. Ces erreurs sont facilement repérabales à l'aide d'un bon EDI (Environnement de développement intégré).

 

Si l'erreur persiste, pensez à vérifier à la ligne précédente!
Par exemple, une erreur à la ligne 26 peut venir d'un ; oublié à la ligne 25!

 

Warning: mysql_fetch_xxx(): supplied argument is not a valid MySQL result resource in...  leFichierPhp.php on line xxx
Ceci n'est pas seulement valable pour MySQL. Mais comme c'est certainement le plus répandu chez les débutants, nous attaquerons par là!

 

Lorsque vous rencontrez ce genre d'erreur, et de manière plus générale, lorsqu'une requête ne change rien à votre base de données pensez à faire appel à la fonction mysql_error() juste après un appel à mysql_query(). Cette fonction vous en dit généralement plus sur l'erreur que vous avez comis lors de la saisie de votre requête en retournant une chaîne décrivant l'erreur en question.

 

Vous pouvez également tester votre requête dans un système d'aide à la gestion de votre base de donnée tel que phpMyAdmin dans lequel vous pouvez saisir directement votre requête et obtennir moultes informations sur les problèmes survenus lors de l'exécution de celle-ci.


Message édité par dwogsi le 26-08-2007 à 16:45:15

---------------
-- Debian -- Le système d'exploitation universel | Le gras c'est la vie! | /(bb|[^b]{2})/
Reply

Marsh Posté le 26-08-2007 à 03:50:15    

Une section liens peut-être?
Edit :
Je transformerais : "Coder avec register_globals à off " par "Coder avec la conf la plus restricitve possible"
Détaillable en sous points.


Message édité par dwogsi le 26-08-2007 à 03:54:06

---------------
-- Debian -- Le système d'exploitation universel | Le gras c'est la vie! | /(bb|[^b]{2})/
Reply

Marsh Posté le 26-08-2007 à 11:00:48    

* Pour les éditeurs sous nux, il y a Qanta si je ne me trompe pas. Tout le monde n'utilise pas VI ou Emacs ;)
 
(moi chuis pas sous nux, mais j'utilise Emacs sous Windows et sous OSX :o :o :o)
 
* Pour Headers Already Sent, il y a aussi le problème du BOM UTF-8 qui, non reconnu par le parseur PHP, est envoyé au serveur web quand il est présent :/
 
* lé ligne -> la ligne
 
* répendu -> répandu
 
* La fin du post est cassée
 
* Il n'y a pas les A, B, C, I, II, III, IV, ... dans le post même, on s'y retrouve pas.


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 27-08-2007 à 09:07:31    

Avec mon enthousiasme du lundi matin, je pose la question désobligeante:
Vous pensez que ça va servir à qui ce topic?
 
Nan parce que :
1- 90% les questions PHP sont pas dans la cat PHP
2- 90% du temps les questions dans la cat PHP n'ont rien a voir avec le langage
Sur les 10% restants, 90% ne font jamais l'effort de lire la doc, pourquoi viendraient-ils lire ce topic?
 
Et sinon, j'emets comme une légère réserve sur le contenu de certains points...
 
Je ne critique pas l'initiative ou les efforts déployés, juste j'interroge :o


Message édité par anapajari le 27-08-2007 à 09:07:55
Reply

Marsh Posté le 27-08-2007 à 11:13:05    

Nan mais ça c'est un topic pour pouvoir envoyer balader les gens en cat php avec un minimum de justifications :o
 
Sinon, faudrait ajouter une partie sur le typage des variables qui est très important même s'il est faible, la différence entre les classes V4 et V5, comment utiliser des exceptions au lieu de die() et puis des trucs de base genre comment fonctionne un cookie (cf ce post), les bases pour utiliser la DOM XML, GD ou encore la fonction mail (les questions qui reviennent souvent quoi)
 
PS : le coca chaud, c'est une horreur


---------------
The Rom's, à votre service
Reply

Marsh Posté le 27-08-2007 à 17:37:56    

réservé

Reply

Marsh Posté le 27-08-2007 à 17:54:49    

Quelques idées de bonnes pratiques, inspirées de ce que j'ai lu dernièrement :
 
register_globals = off (obligation absolue)
 
Quand on travaille sur un script, toujours utiliser error_reporting(E_ALL); dans tous les autres cas display_errors = off et log_errors = on
 
Laisser tombre les long arrays au profit de $_GET, $_POST, $_SESSION, $_SERVER, $_FILES.
 
Laisser tomber opendir au profit de glob
 
Laiser tomber while(list($key, $val) = each($array)) au profit de foreach($array as $key=>$val)
 
Laisser tomber if($x == 'a'){}elseif($x == 'b'){}else{} au profit de switch($x){case 'a': break; case 'b': break; default:}
 
Dans pas mal de cas, laisser tomber fopen, fread et fclose au profit de file_get_contents() ou file() selon l'utilisation (idem pour fwrite et file_put_contents)
 
Très souvent, laisser tomber include() au profit de require_once qui est nettement plus rapide
 
Au sujet des types : pour tester si une variable existe, on utilise isset() et non empty() qui peut provoquer une E_NOTICE. Si on attend un nombre en entrée, c'est une excellente idée que de le préciser en utilisant (int)$_GET['nombre']; empty() c'est très bien :D  
 
Règle d'or : toujours se méfier de données fournies par l'utilisateur.
Même si un formulaire contient un <input type="text" maxsize="2" name="var">, il est possible que $_POST['var'] contienne un fichier MP3 de 3 Mo ... Ne jamais entrer de variable dans une base SQL ou un fichier si elle n'a pas été filtrée, que ce soit son type, sa taille, ou l'échappement des caractères spéciaux.

Message cité 1 fois
Message édité par Bouchon2 le 28-08-2007 à 00:43:27
Reply

Marsh Posté le 27-08-2007 à 17:54:49   

Reply

Marsh Posté le 27-08-2007 à 21:31:31    

Bouchon2 a écrit :


Laisser tomber opendir au profit de glob


 
Ça dépend l'objectif, mais si on cherche du *.* je préfère encore scandir ou opendir/readdir selon le cas, perso.
 

Bouchon2 a écrit :


Très souvent, laisser tomber include() au profit de require_once qui est nettement plus rapide


 
Je dirais même au profit de require qui l'est encore plus, et qui permet de s'assurer qu'on n'a pas deux instructions d'inclusion là où une seule suffirait (évidemment, dans certains cas la version once est utile mais selon moi elle ne devrait être employée que lorsqu'on souhaite explicitement profiter de sa caractéristique). Enfin bref.
 

Citation :


Au sujet des types : pour tester si une variable existe, on utilise isset() et non empty() qui peut provoquer une E_NOTICE. Si on attend un nombre en entrée, c'est une excellente idée que de le préciser en utilisant (int)$_GET['nombre'];


 
Jamais eu d'E_NOTICE avec empty(), tu dois confondre.

Message cité 1 fois
Message édité par sielfried le 27-08-2007 à 21:32:21

---------------
StarCraft Professional Gaming Database | [Ze Topic] Starcraft/BroodWar
Reply

Marsh Posté le 27-08-2007 à 22:02:41    

sielfried a écrit :


Ça dépend l'objectif, mais si on cherche du *.* je préfère encore scandir ou opendir/readdir selon le cas, perso.


Dans la pratique, opendir pose trop de problèmes, en particulier trop de personnes demandent comment supprimer . et .. ; un autre avantage de glob est qu'il retourne des noms de fichiers avec chemin relatifs, donc prêts pour être utilisés avec d'autres fonctions sur les fichiers alors qu'avec opendir le chemin relatif doit être rajouté avant d'utiliser les noms de fichiers dans les fonctions ultérieures ce qui rend le code moins clair.
 

sielfried a écrit :


Je dirais même au profit de require qui l'est encore plus, et qui permet de s'assurer qu'on n'a pas deux instructions d'inclusion là où une seule suffirait (évidemment, dans certains cas la version once est utile mais selon moi elle ne devrait être employée que lorsqu'on souhaite explicitement profiter de sa caractéristique). Enfin bref.


 
Je suis globalement d'accord avec toi, mais comme dans la majorité des cas un fichier n'a besoin d'être inclus qu'une seule fois, le _once est préférable par défaut ; sur SquirrelMail par exemple on a pu constater une baisse du temps de chargement de la configuration (de 30ms exactement sur les 250ms au total) en passant de include à include_once ; les résultats sont encore plus probants quand on utilise un accélérateur comme Zend, du fait que le script est inclus de manière statique dans le bytecode.
 

Citation :

Jamais eu d'E_NOTICE avec empty(), tu dois confondre.


 
empty($_GET['test']); peut provoquer une notice si test n'est pas définie dans la requête GET, ça peut arriver par exemple dans un formulaire avec des checkbox qui ne sont pas définies dans la requete si elles ne sont pas cochées. De manière générale, pour un formulaire, il vaut mieux vérifier que tout est bien défini avec un isset en série (du type isset($_GET['name'], $_GET['firstname'], ...);) et ensuite vérifier si certaines sont vides.
Erreur de ma part, empty est une structure de langage, aucun problème à l'utiliser.

Message cité 3 fois
Message édité par Bouchon2 le 28-08-2007 à 00:42:40
Reply

Marsh Posté le 27-08-2007 à 22:48:09    

Bouchon2 a écrit :

Dans la pratique, opendir pose trop de problèmes, en particulier trop de personnes demandent comment supprimer . et .. ; un autre avantage de glob est qu'il retourne des noms de fichiers avec chemin relatifs, donc prêts pour être utilisés avec d'autres fonctions sur les fichiers alors qu'avec opendir le chemin relatif doit être rajouté avant d'utiliser les noms de fichiers dans les fonctions ultérieures ce qui rend le code moins clair.


Personellement, je ne suis pas trop fan non plus de glob. Maintenant je suis d'accord pour la conseiller à un débutant qui veut pas apprendre le php et se faire un "directory listing" en trois clic!


---------------
-- Debian -- Le système d'exploitation universel | Le gras c'est la vie! | /(bb|[^b]{2})/
Reply

Marsh Posté le 27-08-2007 à 23:23:45    

:hello:  
 
dites moi,
 
je code un nouveau site, et j'essaye de faire mon code de maniere "propre" et re-utilisable (genre pas comme mon premier site :d)
 
mais je ne veut pas pour autant faire un mvc, voici un exemple de mon code (il affiche un mini-chat sur le menu du site) :
 

Code :
  1. // fonction qui affiche les messages dans le mini-chat du menu
  2. function mini_chat()
  3. {
  4. if (isset ($_POST['chat_nom'])) // on ajoute un message si un formulaire vient d'etre posté
  5.  {
  6.  $chat_nom = $_POST['chat_nom']; // recup des variables pour le chat ( nom, message)
  7.  $chat_message = $_POST['chat_message'];
  8.  add_msg_chat($chat_nom, $chat_message); // ajout du message dans la bdd
  9.  }
  10. connection_bdd(); // on se connecte à la bdd
  11. $query = mysql_query("SELECT * FROM chat ORDER BY id DESC" ); // on recupere les messages du chat
  12. $count = 0;
  13. while ($fetch_array = mysql_fetch_array($query))
  14.  {
  15.  $user[$count] = $fetch_array['nom']; // recup du nom  
  16.  $timestamp[$count] = $fetch_array['date']; // recuperation du timestamp du message & formatage en jour MOIS Heure minutes secondes
  17.  $message[$count] = $fetch_array['message']; // recup du message  
  18.  $count++;
  19.  }
  20.  $count = 0;
  21. while ($count < sizeof($user))
  22.  {
  23.  echo '<h6>' . $user[$count] . ', ' . $timestamp[$count] . ' dit :</h6>'; // affichage du nom & du timestamp
  24.  echo '<p>' . $message[$count] . '</p>'; // affichage du message
  25.  $count++;
  26.  }
  27. }


 
est-ce que je me rapproche du modele mvc ? avec la separation des couches (1- requetes sql, 2-affichage) ? faut-il commenter plus ?
 
merci je veut faire du propre  :D

Reply

Marsh Posté le 27-08-2007 à 23:28:14    

Bouchon2 a écrit :


Je suis globalement d'accord avec toi, mais comme dans la majorité des cas un fichier n'a besoin d'être inclus qu'une seule fois, le _once est préférable par défaut ; sur SquirrelMail par exemple on a pu constater une baisse du temps de chargement de la configuration (de 30ms exactement sur les 250ms au total) en passant de include à include_once ; les résultats sont encore plus probants quand on utilise un accélérateur comme Zend, du fait que le script est inclus de manière statique dans le bytecode.


 
Ce que je voulais dire, c'est que si le once ne "fait pas de mal", l'utilisation de la version la plus restrictive quand on le peut permet de s'éviter des erreurs un peut bébêtes (qui seraient masquées dans le cas contraire). J'ai déjà vu des développeurs qui mettaient des require_once un peu partout n'importe comment, histoire d'être "sûr que c'est bien inclus" ; ça leur aurait probablement rendu service de ne connaître que require et de réfléchir un peu plus à l'"arborescence" de leurs fichiers.
 

Citation :

empty($_GET['test']); peut provoquer une notice si test n'est pas définie dans la requête GET


 
Normalement non vu qu'un empty revient a priori à un isset($val) && $val != NULL/0/"0"/etc. J'ai déjà fait des tests empty sur des variables non définies sans soucis, en tout cas, maintenant je l'utilise trop rarement pour savoir s'il est buggé ou s'il a des cas particuliers.


Message édité par sielfried le 27-08-2007 à 23:29:14

---------------
StarCraft Professional Gaming Database | [Ze Topic] Starcraft/BroodWar
Reply

Marsh Posté le 27-08-2007 à 23:41:38    

Bouchon2 a écrit :


Dans la pratique, opendir pose trop de problèmes, en particulier trop de personnes demandent comment supprimer . et .. ; un autre avantage de glob est qu'il retourne des noms de fichiers avec chemin relatifs, donc prêts pour être utilisés avec d'autres fonctions sur les fichiers alors qu'avec opendir le chemin relatif doit être rajouté avant d'utiliser les noms de fichiers dans les fonctions ultérieures ce qui rend le code moins clair.
 


 

Bouchon2 a écrit :


 

Citation :

Jamais eu d'E_NOTICE avec empty(), tu dois confondre.


 
empty($_GET['test']); peut provoquer une notice si test n'est pas définie dans la requête GET, ça peut arriver par exemple dans un formulaire avec des checkbox qui ne sont pas définies dans la requete si elles ne sont pas cochées. De manière générale, pour un formulaire, il vaut mieux vérifier que tout est bien défini avec un isset en série (du type isset($_GET['name'], $_GET['firstname'], ...);) et ensuite vérifier si certaines sont vides.
En y réfléchissant bien, il est possible que ce soit un E_STRICT qui soit provoqué dans les versions récentes, il en avait été question sur la mailing list de PHP.


Je souhaiterais retourner le compliment sur la lecture de doc à ceux qui tenteraient de l'étoffer :whistle:
 
empty retourne un booléen et point, il envoit rien d'autre pas même un semblant d'erreur puisque c'est son boulot de te dire si quelque chose est vide (donc défini sinon c'est que c'est vide de toutes manières puisque ça existe pas :D )
 
Donc le mauvais exemple de dire utilisez isset() au lieu de empty() est vereux :o C'est tout le contraire, empty() fait un isset + un test sur le contenu, donc pour savoir si quelque chose est défini et/ou vide c'est empty(), pas besoin de se poser de question et le test est exhaustif.

Reply

Marsh Posté le 28-08-2007 à 00:41:00    

Au temps pour moi, empty n'est plus une fonction mais bien un opérateur de langage, qui ne génère donc pas d'erreur sur des variables non définies. Faut que je faisse plus attention au changelog...

Reply

Marsh Posté le 28-08-2007 à 00:44:29    

T'es pas fou, moi aussi fut un temps je faisais du isset && !empty, et y'avait forcément une bonne raison! Donc ça devait remonter quelque chose avant en effet, mais ça fait bien longtemps, c'est d'ailleurs ici qu'on me l'avait fait remarqué ;)

Reply

Marsh Posté le 28-08-2007 à 00:45:13    

tomsoft a écrit :

est-ce que je me rapproche du modele mvc ? avec la separation des couches (1- requetes sql, 2-affichage) ? faut-il commenter plus ?
 
merci je veut faire du propre  :D


 
Non, la séparation des couches passe principalement par une séparation réelle dans des fichiers différents. Le but c'est aussi le concept "separation of concerns" ; en fait on essaie définir des couches différentes pour chaque spécialité (HTML, SQL, etc...). Regardes sur le net du côté de "application N-tiers"
 
En gros ça donne (à la va-vite) :
 
1a - filtres divers sur la requête (ex: configurations, choix de la langue, parfois gestion du login)
1b - contrôle pour déterminer l'action à effectuer (peut être considéré comme un filtre, peut remplacer l'URL-rewriting)
1c - vérification des formulaires
1d - réalisation de l'action (utilise 2a)
1e - renvoie la réponse (utilise 2b
 
2a - modelisation, on parle aussi de business model (utilise 3)
2b - vues (en php on parle souvent de templates)
(je met les deux ensemble parce qu'ils sont à peu près au même niveau même s'ils n'ont rien à voir au niveau structure N-tiers
 
3 - DAO, accès aux données (utilise 4)
 
4 - persistence, donne un accès aux données en cachant la base de données et en gérant les transactions et autres détails du genre (utilise 5)
(le principe de la partie 4 est assez récent, j'ai jamais vu en php et peut être évité)
 
5 - bases de données (plusieurs bases possibles si la couche 4 est présente)
 
Séparation des couches, ça veut dire un fichier différent pour chaque point (et par objet à utiliser). Bon tu peux faire moins si tu veux pas un MVC complet mais il faut au moins essayer d'avoir 4 couches :
- contrôles généraux dont le choix des actions à effectuer
- model/gestion des formulaires/actions
- templates
- DAO
 
Voilà et surtout, évites de mettre du code HTML dans un code PHP, même avec des echo "<p>truc</p>"; C'est même pire. Le but quand tu développes, c'est de pouvoir maintenir/corriger/faire évoluer ton code rapidement. Celui qui a pour but d'avoir un site web qui marche rapidement, c'est pas le codeur, c'est celui qui paye pour avoir un site. Dans ton cas, tu sera quand-même plus du côté codeur ...


---------------
The Rom's, à votre service
Reply

Marsh Posté le 28-08-2007 à 08:10:13    

leflos5 a écrit :

T'es pas fou, moi aussi fut un temps je faisais du isset && !empty, et y'avait forcément une bonne raison!


absolument pas


---------------
Stick a parrot in a Call of Duty lobby, and you're gonna get a racist parrot. — Cody
Reply

Marsh Posté le 28-08-2007 à 11:26:54    

TheRom_S a écrit :


 
Non, la séparation des couches passe principalement par une séparation réelle dans des fichiers différents. Le but c'est aussi le concept "separation of concerns" ; en fait on essaie définir des couches différentes pour chaque spécialité (HTML, SQL, etc...). Regardes sur le net du côté de "application N-tiers"
 
En gros ça donne (à la va-vite) :
 
1a - filtres divers sur la requête (ex: configurations, choix de la langue, parfois gestion du login)
1b - contrôle pour déterminer l'action à effectuer (peut être considéré comme un filtre, peut remplacer l'URL-rewriting)
1c - vérification des formulaires
1d - réalisation de l'action (utilise 2a)
1e - renvoie la réponse (utilise 2b
 
2a - modelisation, on parle aussi de business model (utilise 3)
2b - vues (en php on parle souvent de templates)
(je met les deux ensemble parce qu'ils sont à peu près au même niveau même s'ils n'ont rien à voir au niveau structure N-tiers
 
3 - DAO, accès aux données (utilise 4)
 
4 - persistence, donne un accès aux données en cachant la base de données et en gérant les transactions et autres détails du genre (utilise 5)
(le principe de la partie 4 est assez récent, j'ai jamais vu en php et peut être évité)
 
5 - bases de données (plusieurs bases possibles si la couche 4 est présente)
 
Séparation des couches, ça veut dire un fichier différent pour chaque point (et par objet à utiliser). Bon tu peux faire moins si tu veux pas un MVC complet mais il faut au moins essayer d'avoir 4 couches :
- contrôles généraux dont le choix des actions à effectuer
- model/gestion des formulaires/actions
- templates
- DAO
 
Voilà et surtout, évites de mettre du code HTML dans un code PHP, même avec des echo "<p>truc</p>"; C'est même pire. Le but quand tu développes, c'est de pouvoir maintenir/corriger/faire évoluer ton code rapidement. Celui qui a pour but d'avoir un site web qui marche rapidement, c'est pas le codeur, c'est celui qui paye pour avoir un site. Dans ton cas, tu sera quand-même plus du côté codeur ...


 
merci pour les conseils,
 
je vais essayer de voir ce que tu m'as dit =)

Reply

Marsh Posté le 29-08-2007 à 13:26:25    

ma principale remarque concerne essentiellement la définition que tu donnes de php:

Citation :

Php, c'est un langage de script coté serveur, qui permet de rendre des pages web dynamiques. Php s'utilise aussi en mode CLI, en ligne de commande ( lancer un traitement lourd par une requete HTTP alors qu'on dispose d'un accès SSH sur le serveur relève de la connerie pure et simple ).


1- Dire de PHP que c'est un langage de script c'est un abus de langage. Dans le sens traditionnel, un script est une suite de programmes lancés dans un ordre défini. PHP est un langage interprété, ce qui n'en fait pas un langage de script.

 

2- pages dynamiques ça veut rien (ou tout) dire.  
Sauf erreur de ma part, l'appelation historique "html dynamique" c'est une invention crosoft ( dynamic html => dhtml) et désignait l'utilisation de js (puis de l'api DOM) pour modifier la page html après qu'elle ait été chargée.
On peut pas dire que ça s'applique à PHP.

 

3- l'exemple que tu donnes sur un traitement "lourd" n'est pas super. Il est tout à fait possible de lancer un traitement "lourd" détaché d'une requete HTTP sans passer par un accè SSH

 


Au rayon chipotage:
- Sur le nécessaire pour developper en php, un serveur web ne suffit pas. Je peux tout à fait installer WEBrick, c'est pas pour ça que ça supportera le PHP. Par contre y'a pas un mot sur l'interpréteur.

 

- Dans la FAQ, l'ordre est pas terrible. Il eut été plus logique de mettre l'erreur d'interprétation en premier, puis le parse erreur, puis les erreurs de langage.

 

- Je suis pas d'accord sur "l'obligation" de créer un header/footer dans le cadre d'une 1ere séparation des couches. Exemple simple: une page "centrale" qui accueille du contenu par include

 

- Il me semble qu'il serait interessant d'expliquer quelques bases du langage, par exemple:

  • les strings (double et simple quote)
  • l'absence de typage des variables


Enfin voilà :)
Je reprécise qu'il s'agit de critiques que j'espère constructives...

Message cité 1 fois
Message édité par anapajari le 29-08-2007 à 13:26:43
Reply

Marsh Posté le 29-08-2007 à 17:06:03    

Pas mal cette FAQ je vais la recommander à tout le monde et m'empresser de lire certains points que j'ai omis :D
Le require_once me fait gagner un impressionant temps de calcul :]
Une question cependant : est-il bénéfique de fermer la connection sql à chaque fin de requête ?


Message édité par grosbin le 29-08-2007 à 17:21:20

---------------
Photos Panoramiques Montagnes Haute Savoie
Reply

Marsh Posté le 29-08-2007 à 19:57:07    

anapajari a écrit :

2- pages dynamiques ça veut rien (ou tout) dire.  
Sauf erreur de ma part, l'appelation historique "html dynamique" c'est une invention crosoft ( dynamic html => dhtml) et désignait l'utilisation de js (puis de l'api DOM) pour modifier la page html après qu'elle ait été chargée.
On peut pas dire que ça s'applique à PHP.


Alors permet moi, à mon tour, d'émettre certaines reserves sur ce second point.
On parle de pages dynamiques et non pas de html. Et ça fait quand même une différence, suffisante pour ne pas confondre avec le "dhtml".
Et puis... par opposition à "pages statiques", quoi de mieu que d'employer le terme "pages dynamiques".
 

anapajari a écrit :

Au rayon chipotage:
- Sur le nécessaire pour developper en php, un serveur web ne suffit pas. Je peux tout à fait installer WEBrick, c'est pas pour ça que ça supportera le PHP. Par contre y'a pas un mot sur l'interpréteur.


Par contre là je serais tenter de dire que ta remarque est plus que pertinante et qu'elle mérite une place plus importante que le rayon "chipotage".
Un débutant à quand même besoin de comprendre comment fonctionne le tout, donc serveur web, interprêteur et éventuel sgbd. C'est un point important pour comprendre tout ce qui se déroule quand une requête est envoyée au serveur.
D'autre par, pour interprêter du PHP, seul l'interprêteur est indispensable.


---------------
-- Debian -- Le système d'exploitation universel | Le gras c'est la vie! | /(bb|[^b]{2})/
Reply

Marsh Posté le 29-08-2007 à 22:59:46    

dgowsi> fait un google "pages dynamiques" et tu verras qu'on trouve de tout ( y compris un article d'openweb ;) ). Ce que je voulais dire c'est que l'appelation est vague / abusif

Reply

Marsh Posté le 30-08-2007 à 12:12:39    

Non mais je suis assez d'accord avec ce que tu dis, mais là ou je me pose une question c'est...
Si ça ne s'appel pas des pages dyamiques, alors... comment devrait-on appeler ça? Des pages... "changeantes"...?


---------------
-- Debian -- Le système d'exploitation universel | Le gras c'est la vie! | /(bb|[^b]{2})/
Reply

Marsh Posté le 30-08-2007 à 18:05:32    

générées dynamiquement pour le code html rendu? Interprêté dynamiquement pour le code php?

Reply

Marsh Posté le 30-08-2007 à 20:08:03    

Quoique maintenant j'me pose plus la question de la réelle utilitée de pareil débat, mais bon...
Générées dynamiquement, définies comme étant statiques mais éventuellement dynamique par la suite?...
Pages dynamiques côté serveur, côté client on verra?
 
Bon je sort, c'est nimp'....


---------------
-- Debian -- Le système d'exploitation universel | Le gras c'est la vie! | /(bb|[^b]{2})/
Reply

Marsh Posté le 11-09-2007 à 01:42:37    

anapajari a écrit :

dgowsi> fait un google "pages dynamiques" et tu verras qu'on trouve de tout ( y compris un article d'openweb ;) ). Ce que je voulais dire c'est que l'appelation est vague / abusif


Perso j'ai également toujours vu employer le terme "page dynamique" pour désigner des pages HTML générées...dynamiquement xD ( via ASP, PHP, RoR, etc... ) par opposition aux "pages statiques", en HTML pur, dont le contenu ne change jamais ( a moins de réuploader le fichier bien sur :p )

Reply

Marsh Posté le 11-09-2007 à 02:08:41    

C'est du chipottage pour différencier avec la merde que certains ont appelé dhtml, c'est tout...
 
Pas besoin de disserter là dessus, une page générée dynamiquement est dynamique, parce qu'une url donnée peut donner un résultat différent lié à la modification du système entre 2 appels. La limitation est le protocole http c'est tout!
 
Le dhtml c'est du vent, c'est rien ça n'existe pas, c'est juste des goodies grâce au JS qui en soit ne modifie rien mais donne une impression de variation sur clic, faudrait voir à ne pas confondre le client et le serveur, qu'une page gigotte côté client ça nous fait une belle jambe (quand t'en auras deux tu t'achèteras un short :d ), ce qui compte c'est le système donc le serveur et lui il envoit une page générée dynamiquement (on est d'accord sur le terme), mais qui par extrapolation est considérée comme dynamique tout court. A la vue de http elle l'est. A la vue du client elle l'est pas :spamafote: Qui a raison :??:
 
Personne et tout le monde tant qu'on chippotera ;)
 
Si on prend en compte le http, une page qui évolue entre 2 appels est dynamique, ça me suffit à moi :) Puisque c'est le fondement du web le http... Donc dans le contexte une page en php est dynamique, cqfd ;)
 
 
Ce débat ne sert à rien puisque c'est du quequettage sur une définition sans prendre en compte le système complet.  
Dans le sens général, il est impossible d'avoir une page dynamique sur un navigateur ;)

Reply

Marsh Posté le 11-09-2007 à 09:09:16    

Je sais pas à qui est destiné ce gros paté leflos, mais grosso modo tu dis ce que je disais depuis le début: "page dynamique ça veut rien (ou tout) dire" [:w3c compliant]

leflos5 a écrit :

Si on prend en compte le http, une page qui évolue entre 2 appels est dynamique, ça me suffit à moi :) Puisque c'est le fondement du web le http... Donc dans le contexte une page en php est dynamique, cqfd ;)


Mais ce morceau de démonstration ne tient pas vraiment debout, dans la mesure ou je peux avoir une script php qui produit toujours le même résultat html ( juste un print), ou une page html qui n'affiche jamais la même chose ( suppression de noeud aléatoire sur le onload).

Reply

Marsh Posté le 11-09-2007 à 13:14:48    

leflos5 a écrit :

C'est du chipottage pour différencier avec la merde que certains ont appelé dhtml, c'est tout...
 
Pas besoin de disserter là dessus, une page générée dynamiquement est dynamique, parce qu'une url donnée peut donner un résultat différent lié à la modification du système entre 2 appels. La limitation est le protocole http c'est tout!
 
Le dhtml c'est du vent, c'est rien ça n'existe pas, c'est juste des goodies grâce au JS qui en soit ne modifie rien mais donne une impression de variation sur clic, faudrait voir à ne pas confondre le client et le serveur, qu'une page gigotte côté client ça nous fait une belle jambe (quand t'en auras deux tu t'achèteras un short :D ), ce qui compte c'est le système donc le serveur et lui il envoit une page générée dynamiquement (on est d'accord sur le terme), mais qui par extrapolation est considérée comme dynamique tout court. A la vue de http elle l'est. A la vue du client elle l'est pas :spamafote: Qui a raison :??:
 
Personne et tout le monde tant qu'on chippotera ;)
 
Si on prend en compte le http, une page qui évolue entre 2 appels est dynamique, ça me suffit à moi :) Puisque c'est le fondement du web le http... Donc dans le contexte une page en php est dynamique, cqfd ;)
 
 
Ce débat ne sert à rien puisque c'est du quequettage sur une définition sans prendre en compte le système complet.  
Dans le sens général, il est impossible d'avoir une page dynamique sur un navigateur ;)


cherchez l'erreur :lol:


---------------
The Rom's, à votre service
Reply

Marsh Posté le 11-09-2007 à 22:22:08    

anapajari a écrit :

Je sais pas à qui est destiné ce gros paté leflos, mais grosso modo tu dis ce que je disais depuis le début: "page dynamique ça veut rien (ou tout) dire" [:w3c compliant]
 
Mais ce morceau de démonstration ne tient pas vraiment debout, dans la mesure ou je peux avoir une script php qui produit toujours le même résultat html ( juste un print), ou une page html qui n'affiche jamais la même chose ( suppression de noeud aléatoire sur le onload).


Si le code php génère un truc statique il faut se demander si on a fait le bon choix :??:
L'autre exemple se rapproche de cette appellation fourre tout de dhtml.
 
Rien de bien pas logique dans ça :)
 
Quand je dis entre 2 appels, c'est tout confondu, même entre 2 visiteurs, header envoyés, vérification de droits d'accès... Même si ça change pas au final entre 2 accès, il se passe d'autres choses :spamafote: Contrairement à un truc qui est pas généré dynamiquement ou modifié côté client.
 

TheRom_S a écrit :


cherchez l'erreur :lol:


 :whistle:  

Reply

Marsh Posté le    

Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed