Discussion :

[is_null]

Korko Fain : la question sur le jugement de pratique d'echo est bien plus dans le sujet que la question de son utilisation (à ne jammais utiliser selon moi).

Je fais toutes sortes de classe, une rigolote (décorateur) que je viens de terminer pour pouvoir utiliser PEAR dans mon framework : http://pastebin.ca/496851

Au sujet des modèles, j'utilise une classe par objet et pas une classe par table (ce que fais symfony à ce que j'en ai vu pour l'instant) : l'interêt de la classe que je fais étant d'interfacer entre les données d'un objet éclaté en multiples tables avec seulement un seul objet.
Cette classe ne renvoie que des données, j'ai voulu y ajouter des fonctionnalités utilisables directement en smarty alors j'ai fait une autre classe qui étend la première.

Quant à l'usage d'une classe d'abstraction de base de données, c'est selon moi indispensable et personne ne devrait jammais coder sans, ne serait-ce qu'à cause de mysql et mysqli.

Autre argument sur 'bien coder en php', j'en avais oublié un indispensable : toujours laisser le crédit où il est du !

[meliandah]

Pour la commande echo lorsque vous faites des concaténations, PHP créera des variables temporaire indirectement pour assembler la chaîne finale, donc niveau perf le mieux est d'utilisé des virgules si vous voulez mais perso j'aime pas et je concatène très souvent en utilisant des simples quote qui ne lanceront pas le parser dans la chaîne de caractère. Pour ne pas utiliser la commande echo à par en utilisant les fonctions de flux directement je vois pas comment tu pourrai ressortir les variables, et PHP gère mieux le flux que toi, donc autant utiliser les echos :o.
Sinon une classe d'abstraction de la base de données ? CaD ? Une classe qui reflète la base de données ? Il faudra la modifier à chaque mise à jour ou rajout de champs/table dans la base de donnée, sans interférer avec les anciennent fonctions. Perso j'utilise un objet qui se connecte, génére les requêtes et les éxecutes pour me renvoyer le/les résultat(s).
Pour le codage général j'évite au maximum les echos quand même, sa ne sert à rien de mettre des blocs HTML en echo, sa irai plus vite de les mettre en dehors des balises PHP, il so'ccupera tout seul pour vous les mettre dans la flux de sortie.
Sinon on peut très bien créer des page HTML avec les fonctions DOM de PHP... un seul echo final : echo $dom->saveXML(); Mais pour cela il faut une très bonne organisation du projet afin de connaître la structure de ses pages avant, les classes CSS et tout ^^ et créer un objet qui permet de manipuler l'XML pour simplifier un peu le code.

[berceker united]

Pour la commande echo lorsque vous faites des concaténations, PHP créera des variables temporaire indirectement pour assembler la chaîne finale, donc niveau perf le mieux est d'utilisé des virgules si vous voulez mais perso j'aime pas et je concatène très souvent en utilisant des simples quote qui ne lanceront pas le parser dans la chaîne de caractère. Pour ne pas utiliser la commande echo à par en utilisant les fonctions de flux directement je vois pas comment tu pourrai ressortir les variables, et PHP gère mieux le flux que toi, donc autant utiliser les echos :o.
Sinon une classe d'abstraction de la base de données ? CaD ? Une classe qui reflète la base de données ? Il faudra la modifier à chaque mise à jour ou rajout de champs/table dans la base de donnée, sans interférer avec les anciennent fonctions. Perso j'utilise un objet qui se connecte, génére les requêtes et les éxecutes pour me renvoyer le/les résultat(s).
Pour le codage général j'évite au maximum les echos quand même, sa ne sert à rien de mettre des blocs HTML en echo, sa irai plus vite de les mettre en dehors des balises PHP, il so'ccupera tout seul pour vous les mettre dans la flux de sortie.
Sinon on peut très bien créer des page HTML avec les fonctions DOM de PHP... un seul echo final : echo $dom->saveXML(); Mais pour cela il faut une très bonne organisation du projet afin de connaître la structure de ses pages avant, les classes CSS et tout ^^ et créer un objet qui permet de manipuler l'XML pour simplifier un peu le code.

Je suis daccord avec toi mais concernant les requêtes généré automatiquement je dis que c'est moyen . Normalement, si le projet est bien pensé tu n'as pas à bouger la structure de ta base de données sinon cela voudrait dire qu'il y a un problème d'organisation.
Attention au bidouille trop automatisé.
Au début, c'est bien lorsqu'on apprend les possibilités de php mais avec le temps et l'expérience nous comprenons vite qu'il faut faire les choses au plus simple,
- Facile à maintenir,
- Facile à transmettre,
- Rapide à développer
- Facile à faire évoluer

Et même si vous pensez que vous valez mieux que cela. Au moin vous aurez finit votre projet et le client en a rien à carrer que nous ayons fait un truc automatisé, super optimisé dans le code.

[genova]

Bien sur que si le client en a quelque chose à faire : le super truc automatisé et bien pensé fera que les mises à jour seront plus rapides à faire, plus faciles, et moins couteuses

[meliandah]

Justement mon objet SQL je l'ai fait simplement ^^ il faut quand meme lui donner les paramètres de connexion et tu conçois toi même la requête, lui ne fait qu'assembler la chaîne de caractère utilisée pour demander les informations à SQL, je n'aime pas non plus le principe de une classe par table, pour faire cela il faudrai une table avec des champs à perte de vue pour que la classe soit réelement utile.

[sekaijin]

En même temps débattre sur le point ou la virgule ce n'est pas vraiment une question de grande importance.
Surtout que c'est le genre qui ont des chances d'être modifiée par l'équipe de php afin de l'améliorer....

Ce post devrait plutot débattre de technique,choix de conception, d'écriture un peu plus universel à toutes les versions de PHP plutot qu'à quelques broutilles...

Une question qui me trotte dans la tête depuis un bout de temps et à laquelle je ne trouve pas de réponse absolue.

Pour ceux qui développe en OO, lorsque vous concevez vos classes d'accès aux données.
Celles-ci respectent t'elle précisèment la structure de votre base de données (une classe = une table), ou bien cassez vous la structure de votre base de données lors du passage en objet (une classe peut piocher dans plusieurs tables) ?

Perso j'ai opté pour la première méthode, cependant cela n'est pas toujours adapté car ce que l'on peut faire en une requete via la bdd, je le fait en N requetes en utilisant le modèle objet....
En même temps j'ai la hantise d'éparpiller mon modéle de données dans mon modèle objet car lors d'une mise à jour cela imposera de vérifier plus de codes, et certaines portions passeront surement à la trappe.
Ce qui in fine créera de nouveaux bugs...

Vous concernant quels choix avait vous fait ?

bye

Non j'ai dévoloppé une couche d'abstraction de la base avec un mapping obj-relationnel

cette lib me permet de faire du
1 table => 2 classes (la collection et les objets qu'elle contient) cas du 1 pour 1
n tables => 2 classes (la collection et les objets qu'elle contient) cas n pour 1 souvent utilisé pour une table principable et des tables de ref ou ayant une liste de valeur associé à l'objet
1 tables => n classes cas 1 pour n cas de l'utilisation d'une même table pour stocke des objets similaires (dérivant d'un même concept)
n tables => 2m classes cas le plus général

le plus utilisé est le n pour 1 (table de références) et le 1 pour 1
le 1 pour n est très pratique mais se rencontre moins souvent.
le n pour m est le plus puissant est permet de réellement faire un mapping d'un enssemble de classes sur une structure de donnée n'ayant pas de resemblance directe.
je l'utilise souvent dans es développement complexe car il me permet à peut de frait de décoréler le modèle DB du modèle de classe l'evolution de l'un ou de l'autre est plus aissée.

pour les cas 1 1 et n 1 je n'ai pa à écrire de SQL tout est automatique (je peux bien sur en mettre pour amméloirer les perf mais ça marche sans la li génère tout ce qu'il faut)

le cas 1 -n ne demande pas de SQL mais nécéssite de bien construire sa hiérarchie de classe.

le dernier cas peut être fait sans ajout de SQL mais ce n'est pas réaliste (trop gourmand)

au final dans mes prog la couche metier ne présume en rien de la façon dont sont stoqué les objets. la couche controle l'ignore ainsi que la couche présentation.
en gros j'ai un systeme en couche
view
control
metier
mapping
liaison
data

j'utilise aussi une façade entre le contrôle et le metier
ainsi la couche de controle invoque les methodes de la façade sans savoir à qui (metier) revient la responssabilité de faire le boulot

les objets métier eux aussi passent par cette façade il sont aisi fortement découplés et peuvent évoluer indépendamant.

pour faciliter le développement en équipe nous définissons toujours les api de chaque couches avant de les coder (on fait des bouchons) cela permet de disposer du minimum pour commencer à travailler

A+JYT

[Giantrick]

Bonjour à tous,

J'ai parcouru rapidement l'intégralité de la discussion et je vois que vous parlez presque toujours de la balise echo.

Dans beaucoup de livres, et notament PHP5 "3ème édition" de CampusPress, on parle plus de Print que d'echo... une raison particulière ?

Merci de vos commentaires et suggestions !

[berceker united]

Bonjour à tous,

J'ai parcouru rapidement l'intégralité de la discussion et je vois que vous parlez presque toujours de la balise echo.

Dans beaucoup de livres, et notament PHP5 "3ème édition" de CampusPress, on parle plus de Print que d'echo... une raison particulière ?

Merci de vos commentaires et suggestions !

Print c'est surtout un reflexe de codeur d'autre language mais le print à des fonctions en plus par rapport à echo. Maintenant, je dirais que si tu souhaites simplement afficher quelque chose il serait préférable d'utiliser echo que print qui va évaluer ton élement à afficher.

[is_null]

Quelques points de l'XP qui ameliorent largement la qualite d'un projet selon moi :

• usage d'un gestionnaire de versionnage de sources (git, monotone, svn, cvs ...)
• OOP au maximum
• accompagner le projet d'un programme de test d'anti-regression
• et de test unitaire
• demander l'avis d'un binome, au moins sur la conception
• commenter pour un generateur de doc
• ne jamais utiliser print ou echo pour debugger, ecrire un bout de code dans le projet de test a la place.

[vtuning.net]

Salut,

Une question que je me pose depuis un moment en ce qui concerne l'optimisation.

Si par exemple, j'ai une fonction qui va générer en son sein, un tableau de quelques centaines de kilo octets.

Quant la fonction se termine, il vaut mieux faire un unset() du tableau, où la place occupée par le tableau sera automatiquement totalement libérée.

D'un point de vue logique, je pense que le tableau est détruit à la fin de la fonction, mais je ne sais pas comment fonctionne PHP en interne.

Merci d'avance pour vos réponses.

A+

[vtuning.net]

On a tous des habitudes qui nous sont propres, elles peuvent êtres encore plus accentuées si l'on développait sous un autre language avant de se mettre au PHP.

Pour ma part une habitude assez tenace est l'utilisation du " au lieu du '.

J'ai créé un topic assez récemment qui parle des commentaires et de l'indentation.

Ce ne sont que mes avis, mais j'en retiendrai deux choses.

Utilisez des commentaires structurés comme :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
 
//=======================
// Structure principale
//=======================
 
$a = 0;
 
//-----------------------
// Structure secondaire
//-----------------------
 
$a = 1;

et aérez votre code !!!

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
$a = 1;
$string = 'a b c d';
 
if ( $a == 1 )
{
    $array = explode( ' ', $string );
}
 
foreach ( $array as $value )
{
    echo $value;
}

Si non d'un point de vue objet, je n'ai pas trouvé de bons tutos qui définissent réellement ce qu'est la POO.

Je pense coder objet mais je suis sur que ce n'est pas exactement ce que je fais.

En règle générale, voici comment je procède.

J'ai une classe principale que l'on va nommer pour l'exemple "principal".

Elle contient comme membres ce que j'appellerai des membres de premier niveau et comme procédures, les procédures nécessaires à la classe elle même (les plus basiques).

Exemple de membres :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
$principal->url;         // Tout ce qui est passé par l'URL
$principal->cookie;      // Le contenu du cookie

Exemple de procédures :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
$principal->get_url();
$principal->get_cookie();
$principal->send_cookie();

Viennent se greffer des classes secondaires.
Si par exemple, j'ai besoin d'une classe de gestion des images, je vais créer.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
$principal->functions_img = new img;

Ca permet de faire qu'un seul include de $principal et d'avoir tout sous la main.
La simplicité est accrue avec une IDE qui autorise l'autocomplétion. Si les classes et sous classes sont correctement structurées, on navigue dedans comme un naviguerait dans un dossier.

Mais arrive une question à laquelle je n'ai pas réellement trouvé de réponse.

J'essaye de faire une classe par fichier mais il arrive que certains scripts aient besoin de charger plus de 30 fichiers.

Pensez vous qu'il vaut mieux créer de très grosses classes et ainsi limiter le nombre de fichier à charger quitte à n'utiliser qu'une très petite partie de la classe. Ou créer plein de petites classes que l'on chargera au fur et à mesure mais qui consommeront quelques require()?

[berceker united]

Bien sur que si le client en a quelque chose à faire : le super truc automatisé et bien pensé fera que les mises à jour seront plus rapides à faire, plus faciles, et moins couteuses

Le but, n'est pas de faire faire des économies au client sur des mises à jours. Sans ça ta boite tombe.

[sekaijin]

...
Mais arrive une question à laquelle je n'ai pas réellement trouvé de réponse.

J'essaye de faire une classe par fichier mais il arrive que certains scripts aient besoin de charger plus de 30 fichiers.

Pensez vous qu'il vaut mieux créer de très grosses classes et ainsi limiter le nombre de fichier à charger quitte à n'utiliser qu'une très petite partie de la classe. Ou créer plein de petites classes que l'on chargera au fur et à mesure mais qui consommeront quelques require()?

Ne te préoccupe pas du nombre des fichiers de classe à charger. fait une conception cohérente et logique
ja différence en terme de temps de chargement ne sera visible que pour le premier appel de ton script la version compilée de ta classe restant en cache le moteur Zend ne vas que vérifier la date du fichier
donc en temps normal tu moteur vas vérifier 30 dates de fichier à la place d'un c'est tellement pinuts que tu ne verras pas de différence significative.

et la maintenabilité et l'évolutivité de ton appli sera entravé si tu fait un seul gros tas.
A+JYT

[dorian53]

j'ai vu qu'il fallait aussi eviter de couper le PHP avec les balises <?php ?> , donc quelle est la bonne méthode pour inclure le HTML ?

Pour quelle raisons ? De performance ou de lisibilité dans la structuration ?

[UNi[FR]]

Pour quelle raisons ? De performance ou de lisibilité dans la structuration ?

+1 ?

[Sub0]

Pour celles et ceux qui travaillent avec EasyPHP ou Wamp (ou tout autre serveur local), j'ai réalisé un petit utilitaire avec Delphi qui, une fois associé au type de fichier PHP, permet de lancer automatiquement celui-ci comme URL dans le navigateur de votre choix. Par exemple, dans l'explorateur de fichiers, double-cliquez sur un fichier PHP et celui-ci se lancera directement dans le navigateur. Si ce fichier ne se trouve pas dans les dossiers du serveur local, il se lancera avec Notepad ou le programme de votre choix (voir fichier INI du programme pour personnaliser les options). Voici les sources et le programme compilé de ce petit utilitaire super pratique pour le développement php, à copier dans le dossier racine (www) de votre serveur local :

[berceker united]

il a l'air cool cette petite application

[sekaijin]

sauf qu'elle perd beaucoup d'intérêt lorsqu'on utilise MVC
vu que on n'ouvre jamais de script php directement par son url mais en passant par le contrôleur.

une vue sans son contrôleur ne fait rien donc inutile
un contrôleur sans son front contrôleur ne fonctionne pas
un modèle sans contrôleur est inerte

du coup à part le faire sur le fichier index de l'application pour obtenir la page par défaut ça ne sert à rien.

A+JYT

[berceker united]

sauf qu'elle perd beaucoup d'intérêt lorsqu'on utilise MVC
vu que on n'ouvre jamais de script php directement par son url mais en passant par le contrôleur.

une vue sans son contrôleur ne fait rien donc inutile
un contrôleur sans son front contrôleur ne fonctionne pas
un modèle sans contrôleur est inerte

du coup à part le faire sur le fichier index de l'application pour obtenir la page par défaut ça ne sert à rien.

A+JYT

Heuu il y a pas que le MVC dans PHP

[Gavroche7]

Salut
Moi j'aurai conseillé d'organiser les opérations de l'application dans un repértoire appelé 'ops' , suivant deux niveaux : un premier niveau représenté par des repertoires (folders) example :

admin/
articles/
user/
contact/
default/
...etc

et le deuxieme niveau représené par des fichiers xxxxx.php situés dans ces repertoires, examles :

admin/
/set-configurations.php
/view-incoming-contacts.php
/mass-mail.php
/manage-members.php

articles/
/new-article.php
/delete-article.php
/read-article.php
/list-articles.php

user/
/view-profile.php
/edit-profile.php
/set-preferences.php

contact/
/conact-form.php
/conact-insert.php

default/
/home.php

...etc

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