Comment bien programmer en PHP ?

Citation:

---

Envoyé par Gavroche7

...
je trouve aussi qu'il vaut mieu utiliser Vertrigo Serv comme serveur local....

---

Pourquoi celui-là plus qu'un autre ??

* Parcequ'il est plus rapide à démarrer que easyPHP ,

* est parce qu'il supporte PHP5 aors que easyPHP supporte la ersion PHP4.3 (jusqu'à sa esrion easyH1.8 à mon saoir) ,

* et parcequ'il ne crashe pas aussi souvent que easyPHP qui, une fois qu'il présente un problème, il faut formaer son windows et tou réinstaller à nouveau !!

Citation:

---

Envoyé par Gavroche7

* Parcequ'il est plus rapide à démarrer que easyPHP ,

* est parce qu'il supporte PHP5 aors que easyPHP supporte la ersion PHP4.3 (jusqu'à sa esrion easyH1.8 à mon saoir) ,

* et parcequ'il ne crashe pas aussi souvent que easyPHP qui, une fois qu'il présente un problème, il faut formaer son windows et tou réinstaller à nouveau !!

---

http://easyphp.org/telechargements.php3

* bah, faut pas abuser, par rapport au lancement d'eclipse, easyPHP c'est une F1 !

* ding ! pas la derniere version !

* jamais formaté... tu exageres un poil la, tu serais pas marseillais ?!

Citation:

---

Envoyé par Gavroche7

...
De toute façon , c'était mon expérience que je vous ai faits partger,
quanjd à easyPHP j'ai cessé d'utiliser il y a 2 ans , quand il s'agissait de la ersion 1.8,
j'essayerai la dernière version quand j'aurai le temps

---

As tu essayé WAMP5 ?? www.wampserver.com

Très intérressant tout ça, je ne connaissais pas :ccool:
Au fait, pour celles et ceux qui utiliseraient mon petit prog, sachez que vous avez la possibilité de copier plusieurs fois le programme (renommer par exemple firefox.exe ou ie6.exe) et de définir un navigateur pour chacun dans le fichier INI du même nom. Vous pourrez ainsi tester la compatibilité de vos scripts PHP avec différents navigateurs sans difficultés. Perso, pour choisir le navigateur dans lequel le script PHP s'exécutera, j'utilise le menu "Ouvrir avec" du bouton droit dans l'explorateur de fichiers...

J'espère que cela vous simplifiera le développement, à+ ;)

J'avais la même approche que Sub0 avec iMacro pour firefox, j'utilise Selenium depuis, qui permet de faire des assertions en PHP au niveau du client, totalement compatible avec l'AJAX, IE, FF et Safari.

Pour ce qui est du contrôle de versionnage de sources, subversion est très bien lorsqu'on est tout seul, mais on choisira un systême avec décentralisation du dépot comme git, bazaar ou mercurial lorsqu'on est plusieurs.

Pour ce qui est de l'environement de gestion de projet, Trac est à la mode et pour cause : il intègre interface-web à svn et git, un systême de feuille de route, un systême de gestion de tickets (bug, requêtes etc ...), dispose d'une interface CLI, et est vraiment extensible.

phpUnderControl permet de gerer la croisière d'un projet, utile si l'on fait du developpement test-d'abord, mais rapporte aussi les erreurs et avertissement au sujet de la syntaxe aussi bien dans les commentaires PHPDoc que dans le code si vous utilisez des regles pour maintenir la consistence homogene du code dans votre projet. C'est sans parler du detecteur de "bordel", de "copier-coller", et autres statistiques.

PDV fournis une config et des scripts pour etre confortable avec vim en PHP, notamment grace aux fonctions de commentaires PHPDoc

L'usage de linux est indispensable : pouvoir utiliser facilement plusieures configurations afin de reproduire celle du serveur en compilant facilement PHP, HTTP serveur et SGBD.

Enfin, je conseille quelques livres, disponnibles a prix reduit en ebook :

• PHP|Architect : Security
• PHP In Action par Marcus Baker
• PHP5 Power Programming par Derick Rethans
• PHP|Architect : Design patterns

J'espere que ce message inspirera ceux d'entre-vous qui cherchent des techniques pour ameliorer le confort dans le developpement.
Notez que je ne cite que des logiciels libres conformement aux notions democratiques de notre societe evoluee.
Notez que je concois aussi que le controle de qualite des applications developpees a sources fermees ne necessite pas d'impliquer de telles techniques.

Je recommande fortement d'avoir toujours un oeil sur ces liens

http://www.moskalyuk.com/blog/php-op...tion-tips/1272
http://forge.mysql.com/wiki/Top10SQLPerformanceTips

Sur des petits projet on vois pas trop de differenece mais sur des tres gros projet avec une forte frequentation les difference sont monstrueuses (des requetes sql qui prennent 3s, le serveur load qui explose litteralement)

J'ai quelques questions qui me sont venues à l,esprit en lisant plusieurs posts.

1 - Pourquoi des simples quotes plutôt que des doubles? Quelle est la différence?

2 - J'utilise echo comme une fonction normale, c'est à dire avec des parenthèses. Pourquoi plusieurs développeurs n'utilisent pas de parenthèses?

3 - Voici un code exemple, c'est très facile à comprendre et à déboguer pour moi grâce à la coloration syntaxique. Est-ce que fonctionner comme ça pose problème? Faire suivre la même indentation au code PHP ainsi qu'à l'HTML rend le code vraiment clair pour moi.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

<? function ma_fonction() { $query = "SELECT ..."; //Je ne suis pas a l'aise avc le here_hoc $query .= "FROM ..."; $query .= "WHERE ..."; if($query = mysql_result($query)) { ?> <select id="mon_id"> <? while($produit = mysql_fetch_assoc($result)) { ?> <option value="<?=$produit["id"]?>"><?=$produit["nom"]?></option> <? } ?> </select> } } ?>

---

Pour repondre a la question des parentheses la reponse est tres simple: en php les strcutures de controle peuvent etre utiliser sans parenthese. C'est pour ca que tu vois ecrit echo("blabla")/echo "blabla" ou encore include "file.php"/include("file.php").

Sinon desole de te dire ca mais ton code est un exemple de mauvaise pratique en php :P
A mon sens bien programmer en php c'est une architecture MVC (model view controler) qui dans les grandes lignes te dis de separer ton code php de ton code html. Soit en utilisant un moteur de template (smarty, haml et consor) ou comme suivant:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

<?php //ici on inclue un fichier avec toute ses requetes sql et autre operation include "include.php"; ?> <html> <head><title></title></head> <body> <?php if($num_prod > 0){ ?> <select id="mon_id"> <?php while($produit){ ?> <option value="<?=$produit['id']?>"><?=$produit['nom']?></option> <?php } ?> </select> <?php } ?> </body> </html>

---

include.php

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

<?php $query = "SELECT ..."; //Je ne suis pas a l'aise avc le here_hoc $query .= "FROM ..."; $query .= "WHERE ..."; if($query = mysql_result($query)) { $produit = mysql_fetch_assoc($result); }else{ $produit = array(); } $num_produit = count($produit); ?>

---

c'est pas tres propre, c'est procedural, mais ca a l'aventage si tu dois redesigner le site, tu n'as pas a refaire le code. Mais bon on va pas chipoter sur un petit exemple pareil :P

Je comprends ton point, dumoins pour ce qui est de séparer le PHP du HTML, pour ce qui est de l'indentation, j'aime bien pouvoir cerner facilement une balise qui est situé dans une boucle même si cette boucle est en PHP et la balise du HTML.

Je crois que je vais intégrer ces nouvelles notions dans mes prochain projets, il faut toujours évoluer!

Bonjour à tous,

J'ai lu le sujet un peu en diagonale donc je ne suis pas sûr à 100% que ça n'a pas déjà été dit donc je tente quand même le coup.
Pour tout ce qui concerne le nommage des variables, fichiers, classes, l'indentation etc., je vous recommande très fortement de lire la charte de codage proposée par Zend :
http://framework.zend.com/manual/fr/...-standard.html

Sinon je pense qu'il serait intéressant de discuter de la structure interne des classes pour ceux qui codent en objet. Comment les organisez vous généralement (méthodes redondantes, gestion des erreurs etc) ? Utilisez vous des bons vieux accesseurs/mutateurs en dur dans le genre getXXX() setXXX() ou passez plutôt par les méthodes magiques __get __set ?

pas de méthodes redondante je ne vois pas comment on peut en avoir.

pour ce qui est des gestion d'erreur j'applique les règles de Meyer sur la programmation par contrat
J'utilise donc les exception et les traites au plus près. par contre je n'utilise pas d'exception lorsque le contrat n'est pas respecté. en claire je ne lève pas d'exception lorsqu'on me passe un paramètre erroné. je provoque une erreur fatale
Si on appelle une méthode avec de mauvais paramètre c'est que le programme est FAUT ce n'est pas un dysfonctionnement. c'est à l'appelant de savoir ce qu'il fait.

je définit donc des classes d'exceptions propre à chaque package que j'écris.
Cela permet de ne capturer que les exception que je sais traiter à ce moment là.

J'utilise les accesseurs __get et __set lorsque cela est pertinent, le plus souvent les membres de mes classes n'ont pas à être lu ou écrit comme ça, je propose plutôt des méthodes plus ciblées
par exemple getFirstname getName et getFullName et non
getUsrName getUsrFirstName qui correspond aux noms de mes membres

de façon général les membre sont protected ou private. s'il doivent être accédé alors j'utilise __get et __set
A+jyt

Bonjour,

Je me permet d'ajouter une remarque puisque personne (enfin je crois) ne l'a abordé.

Personnellement dès le départ j'ai préféré m'habituer à lire et à coder des instructions IF simples de cette manière :

Code:

---

1 2	$lsVar = ($lsTruc == 'machin') ? 'bidule' : 'muche';

---

équivalent à :

Code:

---

1 2 3 4 5 6 7

if ($lsTruc == 'machin') { $lsVar = 'bidule'; } else { $lsVar = 'muche'; }

---

Si vous préférez cette méthode, il est plus lisible de mettre des accolades pour chaque bloc, même s'ils ne contiennent qu'une seule instruction.
Eviter :

Code:

---

1 2	if ($lsTruc == 'machin') $lsVar = 'bidule'; else $lsVar = 'muche';

---

Je ne sais pas...je déteste ça, après c'est peut-être idiot de ma part.

Et c'est valable pour tous les langages.

De la même manière éviter ce genre de notations :

Code:

---

1 2 3 4 5

$lbTest = false; if ($lsBidule == 'toto') { $lbTest = true; }

---

et préférer :

Code:

---

1 2	$lbTest = ($lsBidule == 'toto');

---

Je trouve ça bien plus lisible et ça évite de surcharger le code.

Après c'est un avis perso :)

Concernant le nommage (ça se dit ça ?:p) normalisé des variables. Il faut réfléchir dès le départ à une convention personnelle. En php plus particulièrement puisque les variables ne sont pas typées.

Exemple :

Local String : commence par $ls
Local Integer : commence par $li
Local Bool : commence par $lb

Pour les variables globales la même chose avec "$g" au lieu de "$l" (même si c'est rare de globaliser des variables en php, enfin pas rare pour certains, mais mieux vaut éviter et définir des constantes, ce qui est plus souple, plus court et plus strict).

etc.

Sinon, tout ce qui est dit dans ce topic est plus ou moins pertinent.
L'idée à retenir je dirai, c'est qu'un bon codeur commence déjà par s'interdir les feintes.
Quelque soit le langage il existe des conventions (nommage, tiens encore ce mot, des variables, indentation, constantes, différentes couches pour le web, etc.) qu'il faut respecter car tout le monde les connait et quand on aborde un nouveau code, nouveau langage et nouveau secteur, on est toujours contents de retrouver ces mêmes conventions.

On ne peut pas vraiment dire : "Comment bien coder en PHP ?", mais plutôt "Comment bien coder ?" tout court. Même si évidemment certains langages apportent des notions supplémentaires, comme la programmation pour le WEB.

Topic très intéressant en tout cas, même si je le prend très en retard.

A plus,

Benjamin.

Je suis en partie d'accord avec toi. Par contre, au niveau des variables, je trouve que c'est inutile de préfixer le type de la variable. Car, je ne vois pas l'intérêt réelle de savoir le type. Avant de connaitre le type d'une variable on cherche à savoir son rôle. Si nous connaissons son rôle nous connaissons son type. Bien évidemment, cela marche s'il y a un certain protocole et que au court du script la variable change de type.

Dans mon protocole, aucune variable à le rôle de prostitué. Ce que j'appelle une variable étant une prostitué est une variable servant à tout et n'importe quoi. :)


A titre personnel, je préfère l'utilisation de variable à courte porté ayant un nom explicite. Le protocole que je me donne c'est au niveau des paramètre. $p_xxxx signifie que la variable provient d'un paramètre de ma méthode et si seulement elle n'a pas été modifié dans la méthode.
Exemple

Code:

---

1 2 3 4 5

private function maMethode($p_parametre){ echo $p_parametre; $maVariable = $this->maMethode($p_parametre); echo $maVariable; }

---

Pour le SQL c'est le même principe. Les paramètre a mes fonctions et procédures stockés p_xxxx et les variables à l'intérieur le protocole est d'utiliser v_xxxx

Citation:

---

Par contre, au niveau des variables, je trouve que c'est inutile de préfixer le type de la variable. Car, je ne vois pas l'intérêt réelle de savoir le type.

---

L'intérêt est personnel. De mon côté, j'utilise la même convention quelque soit le langage. Ca me permet par exemple de connaitre la portée d'une variable rien qu'en lisant son nom (pas besoin d'analyser les blocs).

Ca me permet également au moment d'assigner une valeur à une variable de me rendre compte immédiatement si je suis en train de faire n'importe quoi (par exemple $lbVar = 'toto' alors que c'est un booléen), je sais immédiatement qu'un truc cloche.

Evidemment on maitrise notre code, et en PHP ça n'aura aucune incidence et moins d'intérêt, mais il s'agit là de se construire une logique appliquée à n'importe quel langage et dont l'idée est de savoir que le code peut-être lu par d'autres personnes (je trouve ça plus explicite). Comme je le disais c'est une logique strictement personnelle, après on y trouve un intérêt ou non.

Citation:

---

et si seulement elle n'a pas été modifié dans la méthode.

---

Oui et j'espère que ça n'arrive jamais :) sauf si la fonction se comporte comme une "procedure" et que le paramètre est une référence (opérateur &) à une variable externe à qui on souhaite assigner une valeur.

Encore ici, de mon côté je distingue les paramètres "$pb_param1", pour un booléen par ex., d'un passage par référence "&$pR_param1". Si quelqu'un d'autre lit le code, il comprend alors immédiatement qu'il s'agit d'une référence et fera attention (ou comprendra mieux en lisant les instructions de la fonction).

Personnellement (et ce n'est que mon avis), j'ai utilisé plusieurs style de codage.
Je suis revenu au IF très classique. C'est à dire :

Code:

---

1 2 3 4 5 6 7

$true = true;   if ( $true === false ) { echo 'ok'; }

---

J'évite absolument la syntaxe sensée raccourcir le code.

Par exemple :

Code:

---

1 2 3 4

$a = $b = $c = $d = true;   $a = ( true ) ? true : false;

---

Ce que je conseille en général est d'aérer le code.
Faites le test un code aéré pèse autant en RAM qu'un code compressé devenu quasiment illisible.
De plus, ça permet en un coup d'oeuil de repérer les condition, les boucles, etc...

Je n'adhère pas trop non plus à :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

if (true) { echo 'true'; } else { echo 'false'; }   // Ni à if (true) echo 'true'; else echo 'false';

---

Un peu de lecture :

http://www.developpez.net/forums/sho...52#post2631252

Citation:

---

De plus, ça permet en un coup d'oeuil de repérer les condition, les boucles, etc...

---

Justement, je ne suis pas d'accord avec ça :)
Après comme je disais c'est une habitude, aujourd'hui je lis beaucoup plus vite et d'un seul coup d'oeil les "IF" du type :

Code:

---

$truc = ($machin == 5) ? 'toto' : 'tata';

---

que le reste.
Je précise qu'il s'agit ici de condenser uniquement les IF simplistes qui pour moi, au contraire et s'ils sont nombreux, rendent le code moins lisible.

Citation:

---

Faites le test un code aéré pèse autant en RAM qu'un code compressé devenu quasiment illisible.

---

Je ne parlais pas d'alléger le code d'un point de vue "Machine" mais simplement à l'oeil du codeur.

Oui, l'essentiel est que ta méthode te conviennes.
Fais quant même attention si quelqu'un doit reprendre ton projet.

Par contre, j'utilise quelque fois la méthode dont tu parles pour déclarer des tableaux assez longs. Quoique, je l'utilise de moins en moins.

Code:

---

1 2 3

array( 'abcd' => ( true ) ? true : false, 'efgh' => ( true ) ? true : false );

---

Tu as déja essayé le "code folding" (déplier et replier des bouts de code)? Je trouve ça vraiment pratique en cas de code trop long. Plusieurs IDE le permettent dont Eclipse.

Pour l'histoire des if, je suis partagé.
Il m'arrive d'utiliser ceci :

Code:

---

$var = ($toto==true)?'ok':'pas ok';

---

ou

Code:

---

echo ($toto==true)?'ok':'pas ok';

---

Dans mon projet spécifique qui sera OpenSource, donc susceptible d'être lu par d'autre, je n'ai pas fait le choix de faciliter la lecture pour les autres mais en premier lieu pour moi. Je sais, mais je rentre dans ce cas, j'en finirais pas de me poser des questions. Par exemple, il y a beaucoup de développeurs qui place l'accolade en dessous de la condition.

Code:

---

1 2 3 4 5 6 7

if(...) { ... } else { ... }

---

et d'autre

Code:

---

1 2 3 4 5

if(...){ ... }else{ ... }

---

Je suis de l'école de la deuxième et je ne supporte pas le premier. Avant tout, il faut coder de manière à ce comprendre en premier mais tout en étant pas dans l'optique de compresser pensant que ça va augmenter la vitesse. Je ne pense pas qu'il y ait de gain réelle. Si gain il y a c'est l'ordre de microseconde mais le temps à retrouver ses petits lorsqu'il y a un problème est l'ordre de plusieurs minutes et de "Pfff mais qu'est ce que j'ai voulu faire là!... :evilred: "

Je reviens aussi sur les différentes couches de l'application, fonctionnelle et vue pour simplifier (il y en a d'autres).

Tout le monde parlent de templates et se met en tête de vouloir absolument séparer intégralement le php du html.
Je suis d'accord il ne faudrait jamais voir du HTML dans du PHP, mais l'inverse ? Je me pose la question quand même...

J'ai envie de dire que tout dépend du but final de l'application. S'il s'agit de créer (comme les forums phpbb par ex.), une usine à gaz qui pourra être personnalisée par n'importe qui dans la couche vue sans prendre le risque de modifier la partie fonctionnelle d'accord. Mais je le redis, il s'agit en général d'usines à gaz, et tout le monde sait que les hébergeurs (en mutualisé surtout) n'aiment pas beaucoup ce genre d'application.

Les templates c'est bien, mais ça ralentit quand même considérablement le temps d'exécution.

Maintenant admettons qu'on ait un projet abordé avec une bonne conception Objet, des classes propres et bien construites, n'intégrant aucun html biensur.

Si ce projet était de proposer différents "templates" pour des sites clients permettant de lister par exemple des produits en fonction de critères de recherche (très répandu hein).

Par exemple mes produits seraient des "trucs" ok. Sur ma page d'accueil, j'ai une liste de "trucs" et le détail d'un seul "truc".

Qu'y-a-t'il de mauvais à avoir par exemple :

Code:

---

1 2 3 4 5 6 7 8

// Avant ça création de la connexion à la BDD avec une classe générique // et on aurait au final un objet $db   $listeTrucs = new ListTrucs($db, $id_client); $listeTrucs->getListBySearch($criteres, $_POST);   $monTruc = new Truc($db); $monTruc->getTrucById($listeTrucs->items[0]['id_truc'] );

---

J'invente hein, evidemment ce serait plus réfléchis que ça.

Mais qu'est-ce qui empêche vraiment pour la vue de faire directement dans le HTML :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

<?php $count = count($listeTrucs->items); for ($i = 0; $i < $count; $i++) { ?>   <div id="items-list"> <div class="item"><?=$listeTrucs->trucBidule?></div> </div>   <?php } ?>

---

Ok c'est moins lisible, mais n'est-ce pas bien plus performant ?

Je vous pose la question, la séparation totale des couches a-t-elle un autre intérêt que la lisibilité ? Perso, j'essaie de séparer au maximum aussi, mais je me pose quand même la question sur l'intérêt réel.


Benjamin.

Citation:

---

Envoyé par berceker united

...Avant tout, il faut coder de manière à ce comprendre en premier mais tout en étant pas dans l'optique de compresser pensant que ça va augmenter la vitesse....

---

Aprés on appel ça la maitrise, à force de faire du PHP on commence à savoir quelle fonction est mieux qu'une autre en terme de performances.

Exemple : si ton tableau contient beaucoup d'éléments il est préférable d'utiliser une boucle for plutôt que foreach.

Citation:

---

Envoyé par Delprog

Les templates c'est bien, mais ça ralentit quand même considérablement le temps d'exécution.

---

Petite digression... les templates permettent de faire du code générique, et rendre son code générique permet aussi d'appliquer des concepts génériques dessus comme la notion de cache.

J'avais lu une étude sur smarty pour ne pas le nommer... qui utilise des template et un cache... au final, le cache permet d'avoir un gain sur l'execution et la rapidité par rapport a une version sans cache ni template (bref, sur du code php/html classique) ! Meme si la 1ere génération de page est forcement plus longue, du code PROPRE et PERFORMANT est toujours réalisable avec des templates quand on sait ce que l'on fait.

Citation:

---

Envoyé par Delprog

Ca me permet également au moment d'assigner une valeur à une variable de me rendre compte immédiatement si je suis en train de faire n'importe quoi (par exemple $lbVar = 'toto' alors que c'est un booléen), je sais immédiatement qu'un truc cloche.

Evidemment on maitrise notre code, et en PHP ça n'aura aucune incidence et moins d'intérêt, mais il s'agit là de se construire une logique appliquée à n'importe quel langage et dont l'idée est de savoir que le code peut-être lu par d'autres personnes (je trouve ça plus explicite). Comme je le disais c'est une logique strictement personnelle, après on y trouve un intérêt ou non.

---

Au contraire, il y a que dans un langage non typé que ça a un intérêt. Essaie de mettre un bool dans un int en C++ ^_^, tu le sauras tout de suite que ça cloche. En PHP si tu te retrouves avec un bool en t'attendant à avoir un int tu peux arriver à quelque chose d'un peu chiant à debuguer :D

Au sujet des templates ou encore du MVC, il me semblait que l'un des avantages était la maintenance. Effectivement, si c'est toi qu'a pondu le code la maintenance est plus simple mais si le découpage a été fait par quelqu'un d'autre, ça peut être vraiment galère de remonter à l'endroit qui t'intéresse pour faire juste une petite modif, avec toutes les indirections des fois tu t'en sors pas (à moins d'utiliser un debugger).

Non mais ce que je veux dire, c'est que si on prend par exemple Smarty. Le système de boucle n'est franchement pas plus simple à lire qu'une boucle "for" classique beaucoup plus répandue.

Et si un monteur intervient sur le HTML, je ne suis pas sur que ça change grand chose pour lui. Il ne faut pas être une tête pour piger comment fonctionne une boucle.

Après je sais bien que ça peut avoir d'autres avantages, comme "le codeur code" et le "monteur monte". Mais quand même, si encore une fois je prend l'exemple de Smarty qui est très répandu, nous autres codeurs on comprendra vite le système. Mais un néophyte lui aura déjà beaucoup plus de mal....

Alors quel est le plus facile à lire :

Code:

---

1 2 3

{section name=id_tableau_smarty loop=$tableau_smarty} <li>{$tableau_smarty[id_tableau_smarty]}</li> {/section}

---

Ou :

Code:

---

1 2 3 4 5 6 7 8

<?php for ($i = 0; $i < count($monTableau); $i++) { ?>   <li><?=$monTableau[$i]?></li>   <?php } ?>

---

Je me demande....

Citation:

---

Envoyé par Delprog

Je reviens aussi sur les différentes couches de l'application, fonctionnelle et vue pour simplifier (il y en a d'autres).

Tout le monde parlent de templates et se met en tête de vouloir absolument séparer intégralement le php du html.
Je suis d'accord il ne faudrait jamais voir du HTML dans du PHP, mais l'inverse ? Je me pose la question quand même...

J'ai envie de dire que tout dépend du but final de l'application. S'il s'agit de créer (comme les forums phpbb par ex.), une usine à gaz qui pourra être personnalisée par n'importe qui dans la couche vue sans prendre le risque de modifier la partie fonctionnelle d'accord. Mais je le redis, il s'agit en général d'usines à gaz, et tout le monde sait que les hébergeurs (en mutualisé surtout) n'aiment pas beaucoup ce genre d'application.

Les templates c'est bien, mais ça ralentit quand même considérablement le temps d'exécution.

Maintenant admettons qu'on ait un projet abordé avec une bonne conception Objet, des classes propres et bien construites, n'intégrant aucun html biensur.

Si ce projet était de proposer différents "templates" pour des sites clients permettant de lister par exemple des produits en fonction de critères de recherche (très répandu hein).

Par exemple mes produits seraient des "trucs" ok. Sur ma page d'accueil, j'ai une liste de "trucs" et le détail d'un seul "truc".

Qu'y-a-t'il de mauvais à avoir par exemple :

Code:

---

1 2 3 4 5 6 7 8

// Avant ça création de la connexion à la BDD avec une classe générique // et on aurait au final un objet $db   $listeTrucs = new ListTrucs($db, $id_client); $listeTrucs->getListBySearch($criteres, $_POST);   $monTruc = new Truc($db); $monTruc->getTrucById($listeTrucs->items[0]['id_truc'] );

---

J'invente hein, evidemment ce serait plus réfléchis que ça.

Mais qu'est-ce qui empêche vraiment pour la vue de faire directement dans le HTML :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

<?php $count = count($listeTrucs->items); for ($i = 0; $i < $count; $i++) { ?>   <div id="items-list"> <div class="item"><?=$listeTrucs->trucBidule?></div> </div>   <?php } ?>

---

Ok c'est moins lisible, mais n'est-ce pas bien plus performant ?

Je vous pose la question, la séparation totale des couches a-t-elle un autre intérêt que la lisibilité ? Perso, j'essaie de séparer au maximum aussi, mais je me pose quand même la question sur l'intérêt réel.


Benjamin.

---

Si éléments susceptible d'afficher des données sur l'écran est concentré au même endroit cela ne pose pas de problème pour ma part, il ne faut pas que ça puisse être éparpillé n'importe ou dans l'organisation.
Dans mon cas, j'ai un groupe de classe qui ne fait que du traitement d'affichage. Après, c'est une question de choix.
Je te rejoins sur le faite que le système de template actuelle n'est pas de ce qui est le plus apprécié chez les hébergeurs parce qu'il y a beaucoup d'usine à gaz dans ce domaine.

pour repondre a delprog, je comprend tout a fait ton point et tu as raison de stipuler que l'utilisation de moteur de template (smarty) depend du projet mais aussi de l'environnement de travail. Quand tu bosse seul tu peux te permettre d'etre un peu cochon sur les vues, mais quand tu travail en agence avec des designers, crois mois un if smarty leur fait moins peur qu'un if php.
Mais tu as a pointer un tres bon point concernant "une bonne prog" : choisir ses outils en fonction de son projet. Ca sert a rien de se prendre la tete pour un form de contact (que j'ai deja vu).

Pour bien coder en PHP, je dirais que les règles s'appliquent aussi à d'autres langages.

1 - Avoir une vision globale du projet (ou du bout de projet que l'on nous a confier). Ca permet de bien mesurer les contraintes des solutions que l'on va utiliser.

2 - Avoir des notions de modélisation. Savoir prendre du recul, et ne pas hésiter à utiliser l'abstraction.

3 - Pour un projet Web, bien maitriser les tenants et aboutissants du MVC(2).
A mon avis, il ne suffit pas d'utiliser un framework MVC si on ne comprend pas son intérêt. Un moteur de Templates reste orienté vue. Qu'en est il du modèle ?
C'est à mon avis le plus difficile. Je connais peu de personnes qui maitrisent réellement MVC, et même dans le monde JEE, je suis témoin de sacrées conneries ... Le fait d'utiliser Strust peux donner bonne conscience, mais ce n'est pas suffisant. En php, c'est pareil ...

A la limite, pour débuter, je conseillerai de ne pas utiliser de framework, mais plutôt d'implémenter soi même, simplement, l'architecture MVC. C'est très instructif.

4 - Rester cohérent dans la façon de coder. Peux importe les règles adoptées, si elles le sont au début, elles doivent le rester jusqu'à la fin ...

5 - Faire du code sécurisé : Ne faire confiance à personne, vérifier les entrées (au niveau de la vue, mais aussi au niveau de la base, avec les requetes préparées), etc ...

6 - Pensez si possible à la réutilisation. C'est un exercice difficile, et couteux.
Mais surement avantageux à long terme.

7 - Passer à l'objet pour la couche métier (dans le modèle ;). Et se demander pourquoi les design pattern existent (oui, il y a bien une raison ;) )

8 - Privilégier les architectures simples. C'est souvent oublié, et par élitisme, on tombe souvent dans l'usine à gaz.

9 - Tester la moindre classe. Ne pas hésiter à monter en compétence en tests unitaires. (D'ailleurs, je manque sérieusement d'expérience en TU, si qqun a de bons tutos, qu'il fasse ... péter ^^)

10 - Documenter son œuvre : Eviter les tonnes de documents word incompréhensibles. Quelques lignes bien placés, de petits shemas au besoin, ca marche aussi bien que de longs textes indigestes...

Et j'en oublie surement ...

Citation:

---

Envoyé par mon_nom_est_personne

pour repondre a delprog, je comprend tout a fait ton point et tu as raison de stipuler que l'utilisation de moteur de template (smarty) depend du projet mais aussi de l'environnement de travail. Quand tu bosse seul tu peux te permettre d'etre un peu cochon sur les vues, mais quand tu travail en agence avec des designers, crois mois un if smarty leur fait moins peur qu'un if php.
Mais tu as a pointer un tres bon point concernant "une bonne prog" : choisir ses outils en fonction de son projet. Ca sert a rien de se prendre la tete pour un form de contact (que j'ai deja vu).

---

Je ne suis pas d'accord.
Déjà, ton form de contact fait parti d'une application dans son ensemble.
Si le reste de l'application utilise un moteur de template, pourquoi pas lui ,
Au passage, le moteur de template va utiliser des templates (logique) qui vont apporter une certaine homogénéité dans l'aspect (le design de la page).
Utiliser tes templates te garantie au maximum une coherence dans l'ensemble.

Je voudrais revenir sur un point qui me semble important dans le débat du code PHP avec le HTML.

Voici ce que je retire ma popre expérience :

Je considère que la vue ne doit faire AUCUN traitement en php, si ce n'est que de cracher du HTML.
Le meilleur exemple à mon gout est le moteur de template de PHPbb2 (je n'ai pas vu le moteur de la version 3).

Une classe qui génère un tableau HTML a sa place dans la vue.
Une classe qui calcule le prix total d'un caddie virtuel n'a rien à faire dans la vue.
Une classe qui accède à la base de données n'a rien à y faire non plus.
Une classe qui vérifie les droits non plus ...

Si je pouvais parler à ma couche présentation, je lui dirais :
"Hey mec, toi qui est en charge de d'afficher une page web, je veux que tu la construise avec les données que voici, pour cela, tu devras afficher un tableau, et tout pmleins d'autres choses".

Pour rappel :
Template (Contient du HTML et des balises specifiques simples) + Moteur de template (Contient du PHP qui génère du HTML, ou autre ...) appartiennent à la vue. Il ne doivent pas contenir du code métier, et n'ont pour but que de générer des pages en fonction des données en amont, récupéré du Modèle, mais transmises par le contrôleur.

Alors oui, nous pouvons mélanger le PHP dans le HTML, même si c'est concentré à un même endroit. Mais c'est franchement crado.

Le moteur de template (mais c'est aussi le cas d'autres solutions) a le mérite de forcer le développeur à positionner son code au même endroit.
A long terme, ca évite de se retrouver avec du code métier dans la vue... Chose qui arrive très vite lorsque l'application est maintenue par pleins de personnes différentes au cours du temps.

Citation:

---

si qqun a de bons tutos, qu'il fasse ... péter ^^

---

moi je vous dit si vous avez des tutos pour avoir une bonne maitrise de la MVC et les design pattern ... péter ^^

il y a plain de sites qui parle à gauche et à droite mais pas un vrais tutos qui vous explique les chose.

Je bosse seul :aie: depuis 17 mois sur un projet web en PHP et mnt je me retrouve avec des conneries par tout (une usine a gaz) , et je vois bien l’utilité de la MVC et les design pattern...

Pour utiliser la MVC, Système de Template, TU, design pattern il vous faut une équipe sinon tu te retrouve devant un projet comme le mien ;)

C'est justement pour cela que je dis que la compréhension du MVC est primordiale. Et de ce que j'ai vu sur les dernières pages me fait comprendre que peu ici le maitrisent.

Faire du MVC, c'est contraignant, mais c'est très structurant.
Si le développeur à compris l'utilité de ce design pattern, son code sera logique, et plus facile à maintenir.

Je suis contre ta dernière phrase :
C'est justement au moment ou tu peux t'en sortir seul que tu vois si le MVC a été bien implémenté ....

Programmer en MVC n'est utile que pour les gros projets. Pour des petits sites web par exemple, c'est mettre beaucoup de lignes de codes pour pas grand chose.

Je suis un adepte de la programmation MVC sur les gros projets et non... il n'y a pas besoin d'être toute une équipe pour maintenir un code programmé en POO (dont l'architecture MVC fait partie).

J'ai déjà programmé un projet de plus de 30000 lignes de codes en 6 mois dont environ 20000 pour le back-office grâce à un framework MVC et le maintenir ne me prends que quelques heures par mois.

Citation:

---

Envoyé par david drapeau

Programmer en MVC n'est utile que pour les gros projets. Pour des petits sites web par exemple, c'est mettre beaucoup de lignes de codes pour pas grand chose.

---

C'est aussi très vrai.

Bonjour tout le monde

je parcours ce sujet qui est assez intéressant.

Mais je ne vois pas d'exemple concret de mise en oeuvre d'une architecture MVC "simple", sans utiliser de framework usine à gaz.

pour la vue, le comparatif des systèmes de templates (disponible ici) semble indiquer que la classe de template de phpbb2 est très proche d'une vue "pure" puisque aucune instruction "avancée" n'est présente dans le code.

pour le modèle, les instructions mysqli* semble rassembler pas mal de monde, même si elles sont cantonnées à Mysql, donc pas franchement génériques.

malgré tout, alors que je pense avoir compris le principe de séparation, je n'arrive pas à l'appliquer en pratique. je ne sais pas comment donner à mon modele un objet de base de données, etc.

est ce que quelqu'un pourrait montrer rapidement le code avec par exemple un fichier index.php (controleur) qui va piocher des données quelconques dans une table (en utilisant une classe modele) pour les afficher dans une table html toute simple (en utilisant une classe template phpbb2, par exemple ?)


et comment gérer l'inclusion de pages multiples (les "include" de php) ?

si quelqu'un a le temps et la patience de poster ça, ca serait super sympa, et je pense que ca ferait avancer beaucoup le topic ;-)

Tu peux programmer en couche, comme l'impose MVC2 sans passer par un framework.

A partir du moment ou tu positionnes ton code aux bon endroits, et que le code réalise ce qui est requit à cet endroit, tu codes déjà en MVC.

Je n'ai pas accès à la doc de Phplib (pour le template de PHPbb2) sur le moment, mais je peux deja te donner une piste.

Admettons que tu dois afficher un tableau d'utilisateurs.

voici les fichiers que j'utiliserais

index.tpl (vue)
index.php (vue)
controler.php (controleur)

dataService.php (modele)
sgbd.php (modele)

index.tpl est le template de la page de sortie.
Il represente la vue finale, suite à la requete (tu y mes du HTML et des balises de templates)

Lorsque tu requetes index.php, tu appelle accede à la vue.
Cette vue transmes les informations au controleur.
Là, il n'y a pas de données, mais si il y a un formulaire (par exemple) dans index.php, il faut transferer les données.

controler.php intercepte la requete.
C'est à lui de comprendre ce que veut l'utilisateur, et de lancer les traitements voulus. Une fois les traitements effectués, et les données rapatriées par le modele, il doit rediriger le client vers index.php (qui lui generera la vue vie index.tpl).

Le controleur lance alors une méthode du modèle (qui se trouve dans dataService.php) du genre getUsersList();

Mais comme notre list d'user est en base de données, il faudra que getUserList() appelle elle meme une methode getData() de dataService.php

getData() appellera alors une methode bas niveau (niveau abstraction) de sgbd.php (la requete SQL).

Aussi, si demain, on decide de mettre la liste des utilisateurs dans un annuaire LDAP, par exemple, il faudra creer le fichier ldap.php, et coder la requete dedans.
Dans getData(), on dira simplement de ne plus utiliser sgbd.php, mais ldap.php

Le reste ne doit pas changer.

En retour, le controleur doit recevoir un flux de données venant du modèle.
Ce flux ne doit pas etre formaté, ca sera le role de la vue de faire ca.
On peut tres bien imaginer que la methode getUsersList() retourne un Array, et que chaque ligne de l'array comporte un objet user.

Ta question était, si j'ai bien compris, comment passer du relationnel (la base), à de l'objet.
Tu dois faire un mapping.
Si ta requête sql retourne 4 champs, et que ton objet comporte 4 propriétés, tu dois avoir un bout de code en PHP qui fait la manipulation.

Il y a des tas de mécanisme plus ou moins élaboré qui font ca.
mais c'est archi faisable à la main. POur un petit projet, il ne faut pas s'en privé.

Au final, la couche vue n'a que deux elements avant d'afficher la page :
- la template à utiliser
- Les données à y inclure.

Ais je été clair ?

PS : il n'y a pas de recette miracle, il y a milles et une facon de coder, mais le plus important est bien de comprendre ou se situe les traitements dans les couches. Et pour ca, c'est vrai que faire un petit tour dans le monde de java est très appréciable, et formateur, meme si on n'aime pas Java ;)

PHP est un langage simple donc il est important que le code écrit soit simple aussi.

Bcp de gens codent comme si la ligne de code était payante.
Donc j'évite les profusions de function appelant de function qui appelle des fonctions..Etc

l'important dans une apli PHP, est qu'elle soit immédiatement accessible lors d'un débug ou lors d'une TMA.
L'optimisation du code n'est pas importante car l'évolution matériele (perf) permet de s'en passer : ça coute moins cher d'acheter un serveur avec un meilleur CPU/pluis de RAM que de payer quelqu'un 1 semaine pour venir reprendre le code de quelqu'un.

j'essaie d'illustrer un peu.

Je ne me rappelle plus de la syntaxe de la phplib, donc on va improviser (flemme de regarder :aie: )

je prend un site qui affiche un liste d'utilisateurs dans un tableau, et quand on clique sur un utilisateur dans le tableau, on obtient sa description.
Je poste juste l'affichage, et on verra après où on rajoute le code pour, par exemple, ajouter un utilisateur.

je prends la structure suivante. les dossiers illustrent si je classe tel ou tel fichier / classe dans le M, le V ou le C :

Contrôleur
/index.php le "front controler", si j'ai bien compris
/controleur/top.php qui appelle la vue qui affiche le bandeau en haut de la page. Pas d'infos du modèle , juste un appel à la vue et à un morceau de template
/controleur/users.php qui appelle le modèle pour obtenir la liste des users, puis donne cette liste à la vue pour qu'elle l'affiche
/controleur/id_card.php qui fait la même chose, mais pour un utilisateur seulement

Modèle
/modele/bdd.class.php la classe générique bas niveau qui donne les functions query, etc
/modele/user.class.php va piocher dans la base les infos sur les users, en utilisant les fonctions de bdd.class.php

Vue
/vue/template.php la classe qui contient les fonctions qui parsent les templates
/vue/templates/*.tpl répertoire qui contient les templates, donc que du HTML, et des balises de template


Maintenant les fichiers :

index.php

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27

<?php require('./vue/template.php') //la classe de template, par exemple phplib require('./modele/bdd.class.php') //la classe bas niveau pour les requêtes en BD     include('./controleur/top.php') //appelle la vue qui affiche un bandeau   //le front-controler décide quel morceau de contrôleur doit être appelé, selon l'argument $_GET['page'] if(isset($_GET['page'])) { switch ($_GET['page']) { case 'users' : include('./controleur/users.php'); break;   case 'idcard' : include('./controleur/idcard.php'); break;   default : include('./controleur/default.php')   } }   ?>

---

/controleur/top.php (la syntaxe de la vue est probablement fausse, mais peu importe)

Code:

---

1 2 3 4 5 6 7 8 9 10 11

<?php   $template->choose_template('./vue/top.tpl','template_top'); //je dis quel fichier parser   $template->assign_variable('template_top','logo_top','chemin_image_quelconque'); //je donne l'image de l'image à afficher (exemple quelconque, peu importe. ça ne vient pas forcément du modèle)   $template->assign_variable('template_top','slogan_top','un slogan_quelconque'); //pareil   $template->parse_template('template_top'); //je parse le tout ?>

---

/controleur/users.php (obtient les données sur tous les users, et appelle la vue qui affiche le tableau)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

<?php   $template->choose_template('./vue/users.tpl','users_tableau');   $myuser=new user();   $users=$myuser->getAllUsers();   foreach ($users as $user) { $template->assign_variable('users_tableau','user_name',$user['name']); $template->assign_variable('users_tableau','user_id',$user['id']); }   $template->parse_template('users_tableau');   ?>

---

/controleur/one_user.php (obtient les données sur UN user, et appelle la vue qui affiche sa "id_card")

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

<?php   $template->choose_template('./vue/id_card.tpl','user_idcard');   $myuser=new user();   $user_name=$_GET['username'];   $one_user=$myuser->getUser($user_name);     $template->assign_variable('user_idcard','user_name',$oneuser['name']); $template->assign_variable('users_tableau','user_id',$oneuser['photo']);     $template->parse_template('user_idcard');   ?>

---

/modele/bdd.class.php //les fonctions bas niveau. c'est juste pour l'exemple ;)

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

<?php class bdd {   public __construct($host,$login,$pass,$bdd) { return mysqli_connect($host,$login,$pass,$bdd); }   //ici, au passage, je sais pas comment gérer les requêtes paramétrées : le nombre d'arguments (assimilés à des ? dans une requête paramétrée...) est variable !? public query($sql) { return mysqli_fetch_assoc(mysql_query($sql)); } } ?>

---

/modele/user.class.php //obtient les données sur les utilisateurs
pas vraiment une classe, juste un ensemble de fonctions...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

<?php class user {   //ici : comment la class user connait-elle l'objet $db ? public function getAllUsers() { return $db->query("select * from users"); }   public function getUser($name) { return $db->query("select * from users where name ='$name'"); } } ?>

---

Maintenant les questions :
Comment les fichiers du modèle obtiennent l'objet $db ?
De même, comment les fichiers de la vue obtiennent l'objet $template ?

Ensuite : comment où est ce que j'instancie ces fameux objets ?
dans index.php ?
dans chacun des contrôleurs ?


Voilà. D'autres questions viendront, j'espère faire avancer un peu le topic :)

il faut mettre des explications et bien espacer son code pour qu'il soit lisible

Pour nabbo, je suis dans le même cas que toi, et donc pour que mes méthodes ai accès à mon objet $db, j'initialise l'objet dans mon fichier cfg.php, qui me permet de mettre les paramêtres pour la base de données, et d'ouvir une connexion.

Ensuite, dès qu'une méthode à besoin de mon objet $db, je met un global $db et le tour ai joué, après je sais pas si c'est une bonne solution, mais en tout cas ça marche :)

Citation:

---

Envoyé par samuel.s

il faut mettre des explications et bien espacer son code pour qu'il soit lisible

---

il est aéré mon code... non ?

les explications, j'ai l'impression d'en avoir mis. qu'est ce que tu penses qu'il faut que je rajoute ?

Il est très bien aéré ton code et même très clair. Donc pas besoin de commentaire supplémentaire. Il faut aussi que ceux qui te lisent cherchent à comprendre et ne pas les nourrir mais leur apprendre à jardiner.

Personnellement, je ne mettrais pas de classes dans le répertoire modele/ mais dans le répertoire include/. Et tout ce qui est classes et controlers seraient placés dans ce répertoire include/ car mes controlers sont programmés sous forme de classes.