PHPPRO

Commentaires récents

• kbsali:

  Tres bien presente! :)
  Juste une remarque :
  "$adapter = new CsvAdapter;
  $adapter->setFile('villes.csv');"
  -> Visiblement la methode setFile a ete oubliee dans l'implementation de l'adapter.
  De la meme maniere j'ajouterais une methode setTable() a la classe DatabaseAdapter, ca rendrait ces 2 adapters encore plus versatiles!

  En tout cas merci pour le post!

• Jean-Sébastien H.:

  Plutot qu'écrire du code pour les Mock, PHPUnit a développé un système de bouchon assez puissant.

  Voir la fonction getMock

• Bruno:

  Justement à propos de :
  il manque un test (non unitaire cette fois-ci) qui nous permet de vérifier

  Quelle serait sa forme idéale ? Implémentation, méthode, utilisation ?

• Olivier Hoareau:

  @Bruno: un début de réponse dans mon post : http://blog.phppro.fr/?post/2009/08/14/Tests-d-integration-quezako

• Olivier Hoareau:

  @jsh : tout à fait d'accord avec la présence de cette fonctionnalité intéressante de PHPUnit, pour ma part je préfère réaliser mes mocks moi même car sinon je ne peux pas utiliser de mock en dehors de mes tests unitaires, hors cela peut être intéressant d'utiliser un mock à certains moment du développement (au début du développement d'un webservices par exemple), ou bien dans un autre contexte d'appel que phpunit. D'autre part, je trouve le mécanisme de gestion de la pile d'appel assez verbeux à écrire pour le mock, et je préfère la notion de pile à la "addExpectedResult", plus brute mais plus simple. Mais la fonctionnalité reste intéressante ;)

• Olivier Hoareau:

  Complément d'information posté sur le blog de Clochix (http://www.clochix.net/post/2009/09...) concernant l'utilisation des fonctionnalité Mock de PHPUnit:
  Pour ma part, j'évite de l'utiliser (i.e. la fonctionnalité Mock de PHPUnit) car je souhaite rester indépendant d'un quelconque framework lors de mon développement.

  Les fonctionnalités Mock de PHPUnit sont très intéressantes, elles ont cependant de mon point de vue un défaut majeure dans l'utilisation que je fais des mocks. En effet, lorsque je développe j'utilise la version "mock" de mes classes (adapter) dans mon code tant que je n'ai pas développé la version native (standard). Cela me permet de prototyper / présenter rapidement les fonctionnalités "statiques" de mes développements et de "débrancher" lorsque je suis prêt le mock pour mettre la vraie implémentation (imaginez que je développe un webservice et que je doive rapidement fournir une version de mon webservice pour des consommateurs qui seraient "impatients"). Le problème avec le framework PHPUnit est qu'il n'est pas adapté a priori pour une utilisation en dehors des tests unitaires.
  autre part les mocks peuvent être utiles dans d'autres cas encore que les tests unitaires et celui que je décris, par exemple certains tests d'intégration qui porte sur d'autres zones du code... même remarque dans ce cas.

  Et vous quels sont vos pratiques pour mettre en place des bouchons dans les cas autres que les tests unitaires ?

• stopher:

  Plus je lis vos articles ,
  plus je sent une petite dent contre l'utilisation des FW , ou plutôt une intention de tenter de faire prendre conscience de ce qu'implique l'utilisation d'un FW pour un projet X .

  Si je peux donner mon avis , l'utilisation d'un framework communautaire tel que ZF ou Symphony n'apporte que trois avantages .

  -> Eviter les formations des nouveaux arrivants , l'outil étant connu , il est facile de trouver un développeur ayant un minimum de connaissances sur le FW désiré .

  -> Avoir à disposition une "communauté" en cas de problème lié à cet outil.

  -> Avoir un suivi des failles / bugs

  J'ai donc le même point de vue que vous sur l'utilisation d'un FW tel que le produit Zend ou Sensio Labs .

  L'utilisation d'un framework fait "maison" sera tout aussi valable et performant , à partit du moment ou sa documentation clair et à jour est faite .

  L'avantage selon moi d'utiliser un FW fait maison , est bien entendu d'avoir un contrôle total sur l'évolution de celui-ci , ce qui permet de le faire évoluer en faisant en sorte de rester compatible avec les projets existants , afin d'avoir un minimum de code à adapter .

  Pour ce qui est de la sécurité , pour moi le plus gros risque ne vient pas du framework en lui même , mais bien du code que l'on écrit dans les controllers.

  Voilà donc mon point de vue sur ce sujet .
  Personnellement , j'utilise un FW fait maison ( en entreprise ) qui aujourd'hui a fait ses preuves , et qui me permet d'utiliser les ressources ( certaines libs ) d'autres FW comme le ZF , ce qui me permet de dire , que non la roue n'a pas été réinventée , mais nous restons maitre de l'évolution de la voiture ..

  cdt ,
  Ch.

• metagoto:

  Dans l'ensemble, je partage ton avis.

  Cependant, lorsque le framework en question est du type "full stack" ou encore "super librairie", le développeur sera naturellement tenté et même guidé pour ne rien inventer du tout et ce jusqu'à la partie applicative. Tout est pré-mâché si je puis dire. Peut-on lui reprocher de suivre aveuglément les conventions et good practices dudit framework? Injecter du "custom code" (comprendre découplé au niveau de la librairie) sera au mieux un second framework dans le framework et au pire un calvaire de plus à appréhender pour les collègues (si tant est que l'individu a des collègues;)

  Et si le problème sous-jacent était une question de compétence, tout simplement ? Maîtriser convenablement le langage, php en l'occurrence, ses idiomes et son domaine d'application me semble être l'élément primordiale pour ne pas se faire piéger par un framework, ou à contrario, en reconnaître les qualités.

• Olivier Hoareau:

  @metagoto: merci pour ton point de vue très intéressant.

  @stopher: merci pour ton retour d'expérience !

• stopher:

  Effectivement , les compétences dans le langage entrent en jeu .

  Un développeur peu expérimenté ( ici en php ) se lance dans l'apprentissage et l'utilisation d'un framework les yeux fermés , car c'est le plus connu ou par effet de mode , ne me semble pas vraiment recommandé .

  Le développeur en question fera un peu office de "presse boutons" .

  Les FW aujourd'hui sont très complets , en terme de sécurité , de connectivité , de gestion de flux , d'affichage ect ..

  Mais si aucune étude sur les rouages qui se cachent derrière , et sans avoir d'expérience au préalable , le jour ou il se retrouve sans l'outil magique et puissant qu'est le FW aujourd'hui ( tout du moins les plus grands ) , le développeur risque d'être perdu , bref de ne plus savoir coder correctement le moindre petit projet sans ce genre d'outil .

  Maintenant , je reconnais qu'une personne qui utilise un FW aussi complet que le ZF , ou Symfony ( pour l'avoir utilisé ), possède tout de même un minimum de compétences pour savoir les utiliser et en tirer profit .

  C'est peut-être (et certainement même) juste une crainte personnelle de voir les FW devenir une sorte de couche d'abstraction tel que le nouveau développeur développera et ne saura développer qu'à partir d'un FW , sans avoir de connaissances solides sur les mécanismes (de plus bas niveau donc ).

  Ch.

• Mère Teresa:

  Comme c'est bien exprimé :
  "Et si le problème sous-jacent était une question de compétence, tout simplement ? Maîtriser convenablement le langage, php en l'occurrence, ses idiomes et son domaine d'application me semble être l'élément primordiale pour ne pas se faire piéger par un framework, ou à contrario, en reconnaître les qualités."

• jpauli:

  Je reprends Mère-Téresa et son quote, c'est si bien exprimé!

  Le problème est là : il faut une **parfaite** maitrise de PHP5 pour faire joujou convenablement (comme tu le décris Olivier) avec un FW.

  Il faut une **très bonne voire parfaite** maitrise du génie logiciel pour faire joujou convenablement avec un FW.

  Sans l'un ou l'autre, le FW est une *tare* qui *ralentit* les projets voire même les fait* couler*.

  Les gens n'ont pas compris ça, en majorité; ils n'ont pas compris que pour apprendre à conduire un bus, il faut savoir piloter parfaitement une voiture,
  comme ils n'ont pas compris que l'informatique vue de haut ce sont des couches qui s'empilent comme un oignon: qui osera faire du PHP sans maitriser C ? Qui osera manipuler le FW XYZ sans maitriser PHP ?

  Qui osera se pencher sur la couche de niveau N sans maitriser (ou au moins être très au courant) la couche N-1 ?
  Ca mène à des catastrophes très souvent ;-)

• Hervé:

  Merci pour l'article Olivier, comme d'habitude c'est intéressant

• metagoto:

  J'utilise ArrayAccess quand j'ai besoins de l'interface compatible array, à laquelle s'ajoutent généralement Countable et un Iterator. C'est d'une banalité affligeante ;)

  Le gros défaut est que php interdit de redéfinir une méthode avec une signature différente. On ne peut donc pas y injecter du type hinting, ou alors on le fait de manière détournée dans le corps de la méthode.

  Par exemple un ORM. Une property modélise une relation 1-N vers des types T. Celle-ci expose un "ArrayAccess" pour que l'utilisateur puisse y ajouter des types uniquement compatibles avec T. Ce comportement ne serait pas possible si la property n'était qu'un simple array dans lequel on peut ajouter ce qu'on veut.

• Laurent Sarrazin:

  Tout à fait d'accord avec le post moins avec le commentaire de Julien :)
  Heureusement que tous les développeurs PHP n'ont pas à maîtriser C sinon la communauté serait nettement réduite...