Posts Tagged ‘PHP’

Le contexte : une application PHP/MySQL, un champ BLOB dans l’application avec Symfony. Par défaut, nous avions laissé Propel pour faire nos tests.

Le souci d’un champ BLOB est sa contenance. Lorsque je veux lister tous mes enregistrements, si un des champs est BLOB, il est difficile de l’afficher directement dans le listing. Au niveau de la modélisation, j’ai donc intérêt à prévoir que ce champ sera ramené plus tard.
Symfony-Propel me propose une technique : préciser dans le YAML que ce champ sera rapporté à la demande.
commentaires_longs: {type: blob, lazyLoad: true}

Ensuite, lors de la récupération, j’ai tout intérêt à proposer un lien vers le contenu long (en saupoudrant éventuellement d’Ajax pour fournir à l’utilisateur une prévisualisation au survol). Il serait en effet trop coûteux de rapporter ce champ, en performance et en place sur la page web.
Au moment où je souhaite obtenir le commentaire, je pourrais faire :
$criteria->clearSelectColumns();
$criteria->addSelectColumn(ObjetPeer::COMMENTAIRES_LONG);
$rs =ObjetPeer::doSelectStmt($criteria);

Attention : actuellement, la méthode est doSelectStmt() et plus doSelectRS(), ne vous faites pas avoir.
Ensuite, vous récupérez un objet de la classe PDOStatement, il faut ensuite l’exploiter avec un fetch().

Au niveau de la conception de l’application, on peut imaginer mettre ces champs longs dans des tables séparées, puisqu’il sera rare qu’on les reprenne en même temps que les autres.

Publicités

Quand je force un tableau associatif en objet, il devient un objet ayant les propriétés qui étaient les clefs du tableau.

Quand je caste un objet en tableau, le nom des propriétés deviennent des clés du tableau, prenant leur valeur.

On connaît la fonction count() en PHP, qui permet de connaître le nombre d’éléments d’un tableau. Mais si je veux savoir à quelle profondeur je risque d’être conduit en parcourant récursivement mon tableau, comment faire ?

J’en profite pour vous faire découvrir le deuxième argument de la fonction count(), qui mis à la valeur COUNT_RECURSIVE prendra en compte les éléments internes du tableau.

Je reprends l’exemple de la doc PHP pour éclairer mon propos.
$food = array(
'fruits' => array(
'orange', 'banana', 'apple' => array('verte', 'jaune', 'rouge')
),
'veggie' => array(
'carrot', 'collard', 'pea'
)
);
// count récursif
echo count($food, COUNT_RECURSIVE); // affiche 11 et non 8

Parmi les fonctions de tableau, il n’en existe aucune qui permet de juste obtenir la profondeur d’un tableau.
La raison, à mon avis, est qu’un tableau peut-être multi-dimensionnel de manière inégale, comme dans mon exemple ci-dessus.

A quoi sert l’accès statique ?

Dans le manuel PHP, il est dit :

Le fait de déclarer des membres ou des méthodes comme statiques vous permet d’y accéder sans avoir besoin d’instancier la classe.

Donc, l’utilité des accès statiques serait : de ne pas avoir besoin d’objet

Par extension, l’idée est donc de regrouper les méthodes d’une classe dans un conteneur, et ainsi de pouvoir nommer deux méthodes du même nom, et de pouvoir charger le code de ces deux méthodes, car elles appartiennent à une classe différente, ce qui n’est pas possible avec de « simples » fonctions.

Exemple :

include(‘Viande.class.php’); include(‘TarteAuxPommes.class.php’);

Viande::manger();

TarteAuxPommes:manger();

Un stagiaire me propose une définition différente

edit du 8 juillet 2008
une méthode ou un attribut statique est partagé par toutes les instances/objets de la classe, du fait de ne pas dépendre d’un objet en particulier.
ex : un randomizer partagé par toutes les instances ou encore un compteur qui compte le nombre d’instances en cours.

Dans une fonction, en PHP, on peut accéder aux variables externes à la fonction en utilisant le mot-clef global, ou le tableau $GLOBALS. Ces variables sont alors passées par référence : les modifier dans la fonction revient à les modifier dans le script appelant la fonction.

10 mythes sur PHP dévoilés

Ce qui suit est une traduction de 10 PHP Myths Dispelled, publié le 2 janvier 2008 par Jaybill McCarthy

Je suis un développeur PHP. Peut-être même la moitié d’un vrai développeur. En tant que tel, je me suis souvent retrouvé mêlé à des conversations sur le développement des applications web en général et sur PHP en particulier. Je suis continuellement frappé par les mythes, les demi-verités et de vrais mensonges que les gens autant techniques que non-techniques propagent sur cet humble langage de programmation.

Je suis loin d’être un fanatique sur quoi que ce soit de logiciel. Je pense que si vous êtes passionné d’un logiciel, vous ratez le coche. C’est comme si un charpentier était passionné de marteaux au lieu de construction de maisons. En ayant dit cela, je sens que je dois vraiment dissiper quelques malentendus avant qu’ils ne prennent plus d’importance : je suis fatigué d’être pris de haut par les développeurs Java qui croient que leur choix de langage est Le Seul Vrai Chemin. Donc voici ma liste.

Mythe n°1 : PHP n’est pas vraiment un langage orienté objet
J’ai entendu cela de beaucoup de développeurs Java. C’est complètement faux. PHP a un excellent bagage OO. Il y a l’héritage, les classes abstraites, les interfaces, les propriétés et les méthodes. D’accord, il n’y a pas de surcharge de méthodes, mais il y a moyen de contourner cela. Seul le binding est encore un peu immature. Je dirais qu’il y a eu de grands progrès dans les mécanismes OO avec PHP5, mais j’ai aussi écrit beaucoup d’applications PHP4 qui étaient complètement OO. Le seul fait que vous pouvez écrire du code complètement procédural en PHP ne signifie pas que PHP ne peut pas faire d’objet. En outre, le fait que PHP vous autorise à mélanger objet et procédural rend les choses comme le bootstrap vraiment simple.

Mythe n°2 : PHP encourage le mauvais code
Egalement faux. Y a-t-il beaucoup de mauvais code PHP ? Absolument. La barrière d’entrée faible de PHP signifie que beaucoup de gens qui ne sont pas des développeurs formés entrent dans la danse.

Le mauvais code qui en résulte est la conséquence d’une formation faible et d’une mauvaise gestion, non du langage lui-même. Dire que PHP encourage le mauvais code, c’est comme dire que les mateaux encouragent les doigts ensanglantés. Evidemment, vous pouvez vous taper sur les doigts avec un marteau, mais est-ce de la faute du marteau ou vous qui ne savez pas comment l’utiliser correctement ?

Mythe n°3 : PHP ne suit pas le modèle MVC
Je sais que cela paraît ridicule, mais je ne sais pas avec combien de Railers j’ai eu cette discussion. Non, PHP ne fournit pas, de lui-même un framework MVC. Pas plus que Ruby, ou aucun autre langage, d’ailleurs. C’est parce que Ruby et PHP sont des langages, et non des framework d’application. MVC est un design pattern, et non une possibilité du langage. Il existe beaucoup d’excellents frameworks MVC écrits pour PHP. J’aime le Zend Framework. Pouvez-vous faire un appel à la base depuis un script qui générerait aussi le HTML ? Bien entendu, vous pouvez. Est-ce que cela veut dire que vous devez ? Non.

Mythe n°4 : PHP est lent parce qu’il est interprété
Celui ci est insidieux parce que cela semble plausible. En fait, cela devrait être vrai. En pratique, cela ne l’est pas. Le Zend Engine qui fait tourner la plupart des implémentations PHP est incroyablement rapide de base. Combinez le avec un accélérateur, (comme eAccelerator, libre) qui pré-compile et cache le code (et qui l’adapte si on change de disque), et c’est l’une des plate-formes d’applications la plus performante actuellement, même comparé à des choses qui sont traditionnellement compilée comme Java et .NET. Même en écrivant votre appli en C ou C++, en le compilant et en l’intégrant à votre serveur web, vous n’aurez pas plus de performances.

Mythe n°5 : PHP n’est pas de bon EDI ou de débogueur
C’est vrai. Il n’y en a pas un. Il y en a plein. Il y a au moins deux débogueurs, et plein de bons EDIs. Vous pouvez avoir toutes les options que vous voulez, comme les points d’arrêt, la surveillance des variables, l’évaluation au passage de la souris, etc. Pouvez-vous utiliser un éditeur texte et un client FTP ? Bien entendu, vous pouvez. Vous n’êtes certainement pas obligés, je pense.

Mythe n°6 : les applis PHP se ressemblent toutes
Je dois le dire, cela m’a pris longtemps pour comprendre ce que les gens qui déclaraient ça voulaient dire. Au départ, j’ai pensé que la personne disant cela était folle. Après tout, PHP est juste un langage, vous pouvez faire que la sortie soit…comme vous la voulez ! De façon surprenante, j’ai beaucoup entendu ça. Par la suite, j’ai compris que la confusion provenait de profils non-techniques qui confondaient PHP et PHP-Nuke, qui est juste une application écrite en PHP. Elle est complètement personnalisable, mais propose des colonnes et des pavés qui ont tous le même genre d’apparence.

Mythe n°7 : PHP n’est pas vraiment pour les « vrais » développeurs
C’est un autre que j’ai entendu des développeurs Java (et encore plus amusant, des développeurs .NET). Comme le n°2, je pense que cela provient de la faible barrière d’entrée pour PHP. Quasiement tout le monde peut apprendre les rudiments de bidouillage de scripts PHP en un après-midi. Est-ce que cela signifie qu’il n’y a pas la place pour des « vrais » développeurs ? Bon, PHP, comme toute plate-forme de développement est un outil. La façon dont est utilisé un outil varie grandement selon les connaissances et l’expérience de la personne qui l’utilise. J’ai écrit plein d’application PHP de grosse taille, robustes et performantes, et je ne suis pas le seul.

Mythe n°8 : PHP n’est bon que pour les applications web
C’était vrai par le passé, mais de nos jours, il est beaucoup plus universel. Vous avez un interpréteur de ligne de commande qui peut tourner de manière complètement indépendante d’un serveur web (pour des scripts) mais peut continuer à utiliser vos bibliothèques existantes de code PHP. Vous pouvez même créer des applications avec une interface graphique, par PHP-GTK.
Evidemment, le but initial de PHP et sa visée étaient les applications web, mais c’est bien loin de tout ce qu’il peut faire.

Mythe n°9 : Le code PHP est un tas d’ « include » et de « require » qui se cassent facilement
En tant que langage de script, PHP est interprété à la volée. Cela signifie que n’importe quel code qui est exécuté doit être pris sur le disque et le script en question a besoin de savoir où il se trouve. La plus simple (mais la moins bonne) manière de faire est de mettre un « include » ou un « require » qui charge le script externe. Si vous faites cela et que vous renommez le fichier, votre code est cassé, à moins que vous ne modifiez l’instruction erronnée. Un tas d’include et de require peut faire de votre code un tas de spaghetti.

Heureusement, en suivant les règles de la programmation OO, des bonnes conventions de nommage et en utilisant __autoload__ les include et require sont généralement complètement intules. __autoload__ est une fonction de callback qui accepte en argument le nom d’une classe. Si vous instanciez un objet, et que le moteur ne sait rien de la classe, il appelle votre __autoload__ avec le nom de la classe en tant que chaîne. En présumant que vous avez une convention de nommage raisonnable (une classe par fichier, le nom de la classe et le nom du fichier correspondent), c’est plutôt simple de charger la classe au moment voulu. Cela a l’avantage de ne charger que les classes nécessaires pour un script particulier, au lieu de les charge toutes avant même le début du code fonctionnel.

Mythe n°10 : Le code PHP est bourré de requêtes SQL
Jetez un oeil aux applications PHP et vous le verrez. Le SQL a été mêlé avec des chaînes et passé à la base (souvent MySQL) avec les fonctions spécifiques. Cela rend votre code fragile, lourd à déboguer et à maintenir et sujet aux attaques par injection SQL. C’est aussi complètement inutile et peut-être facilement évité. Utilisez simplement une couche d’abstraction comme Zend_DB ou ADOdb au lieu de parler directement à la base.

Voilà, c’est fait. Les dix mythes sur PHP sont littéralement…heu…explosés. Cela ne signifie pas que PHP est sans défaut, mais je pense que peu d’autres outils ont cette mauvaise image.
J’espère que j’ai un peu éclairci les choses.

On retrouve souvent le mot expression dans la documentation. Notamment avec le fait que print peut faire partie d’une expression, n’étant pas une fonction mais une structure de langage, alors qu’echo ne le peut pas.

La page de PHP.net dédiée aux expressions est assez claire :

En PHP, presque tout ce que vous écrivez est une expression. La manière la plus simple de définir une expression est : « tout ce qui a une valeur ».

PHP est un langage orienté expression, dans le sens où presque tout est une expression.

De façon étonnante en PHP, on peut accéder à une propriété privée de la classe mère, depuis la classe fille, en utilisant une méthode non-redéfinie dans la classe fille. Cela reste dans la logique de PHP, puisque la méthode utilisée est celle de la classe mère

</pre><br />
<pre>class Gateau{<br />
        private $nbParts = 6;</p>
<p>    public function vendre($nbParts, $destinataire)<br />
    {<br />
        echo 'Je vends '.$nbParts. ' parts de gâteau à '.$destinataire;<br />
    }</p>
<p>    public function getParts()<br />
    {<br />
        echo ' Mon objet '.__CLASS__.' a '.$this->nbParts. ' parts.';<br />
    }<br />
}</p>
<p>class Tarte extends Gateau{<br />
    private $nbParts = 8;</p>
<p>    public function vendre($nbParts)<br />
    {<br />
    //Je définis une méthode de la classe fille, dont le prototype m'indique<br />
    // que j'ai  plus d'arguments que la mm méthode de la classe mère</p>
<p>    echo 'Je vends '.$nbParts. ' parts de gâteau';<br />
    }<br />
}</p>
<p>$pie = new Tarte;<br />
$pie->vendre(5);<br />
$pie->getParts();// j'accède à la méthode parente, donc au nb de parts de la classe parente</p>
<p>

Pour les requêtes préparées, avec PDO, on peut mettre en place, lors du binding des arguments, un filtrage sur le type attendu.

La documentation donne des exemples pour les méthodes

/* Exécution d'une requête préparée en liant des variables PHP */
$calories = 150;
$couleur = 'rouge';
$sth = $dbh->prepare('SELECT nom, couleur, calories
    FROM fruit
    WHERE calories bindParam(':calories', $calories, PDO::PARAM_INT);
$sth->bindParam(':couleur', $couleur, PDO::PARAM_STR, 12);
$sth->execute();

Que se passe-t-il lorsque j’envoie un mauvais type ?

PDO s’occupe de caster les variables pour qu’elles correspondent au type attendu.
avec PARAM_INT, si on propose une chaîne, elle devient la valeur 0
avec PARAM_STR, 15 (longueur max de chaîne), la chaîne est tronquée à 15 caractères.

En PHP5, avec l’amélioration de la POO, on a la possibilité de mettre en place des constantes de classe.

Ces constantes permettent d’enregistrer une valeur qu’on réutilise et qui n’est pas modifiée. Ces constantes ne sont accessibles que de manière statique, depuis la classe, et non pas depuis une instance de la classe.


classe Tarte{

const NB_PARTS = 8;

}

//pour y accéder, je dois le faire en statique

echo Tarte::NB_PARTS;