PHPPRO

Commentaires récents

• Mat:

  Hello, merci pour cet article.

  Une petite alternative : personnellement je met un nom de domaine comme nom de sections pour mes fichiers .ini de configuration.
  Coté applicatif je detecte le domaine utilisé et je charge la configuration correspondante.

  Ca permet à la fois de gérer les environnements de développements différents et également de mettre des paramètres spécifiques à certains domaines (ex: locale par défaut fr_FR pour example.fr et en_Us pour example.com).

• NiKo:

  Pour info, pour gérer cette problématique dans symfony on a les outils suivants :
  http://www.symfony-project.org/book...

• Gérald:

  C'est typiquement le genre de syntaxe dont on est très friand dans Copix :-)

  Il faut avouer que cela simplifie l'écriture.... par contre on se retrouve vite avec des syntaxes compact dont il faut connaître la signification :-)

  _dao ('MaTable')->findBy (
  _daoSp ()->addCondition ('champ', '=', $valeur)
  ->addCondition ('champ2', '=', $valeur2)
  ->orderBy ('champ3')
  )

  Ce qui ici signifie : Je vais récupérer dans ma table "MaTable", grâce à un "Data Access Object", les enregistrement qui correspondent aux paramètres de recherches (daoSP = Data Access Object Search Params) ....

  Le plus proche de l'exemple serait la fabrique de classe, utilisée de la sorte :

  _class ('classId')

  ...qui retourne un new 'ClassId' (en plus d'inclure le fichier en question grâce à un système d'autoload).

  J'aime assez aussi la possibilité de faire un raccourcis pour obtenir des singletons de ces objets, avec par exemple

  _ioClass ('classId');// (instance of class) qui retournera systématiquement la même instance de la classe 'classId'.

  En tout cas c'est sûr, le nested call de PHP 5 est pour moi une grande nouveauté par rapport à la version 4 :-)

• Hugo:

  Merci beaucoup pour ce petit billet très instructif ;)

• graffiti:

  Mais comment n'y ai je pas pensé avant ?

• Hugo:

  1/ Ok !
  2/ Ok mais ça c'est de l'utopie ^^
  3/ Ok mais je préfère le commit atomique à chaque modification mineure
  4/ Ok !
  5/ Ok mais pas toujours faisable. La capitalisation du code n'est pas toujours possible en fonction des spécificités de chaque projet.
  6/ Tests fonctionnels ou unitaires ? Dans l'idéal il faudrait les deux :)
  7/ Ok !
  8/ Tu entends quoi par là ?
  9/ 80 c'est presque trop. Dans la plupart des cas, on peut s'en tirer avec une trentaine / cinquantaine de lignes.
  10/ Toujours :)

  Tu as oublié un commandement important :

  11/ Les commentaires PHPDoc tu utiliseras et ton code, intelligemment et efficacement, tu commenteras.

• Bast:

  s/du développeur PHP/du développeur/

• ED.:

  Pareil que Hugo, j'ai tendance à préférer les commits atomique.

  1° C'est plus facile à "revert"
  2° Ca oblige le développeur à travailler sur des micro blocs testés

• Gab:

  Disons que c'est des bonnes pratiques pour tout codeur en général, pas spécialement PHP (du coup ok avec Bast: s/du développeur PHP/du développeur/ )
  et c'est un peu trop orienté TDD: après tout, on est pas OBLIGE d'en faire, non?

• Olivier Hoareau:

  @Gab : on est pas obligé de faire du TDD, par contre les tests unitaires c'est quand même un incontournable si tu veux développer de la qualité. TDD t'apporte la rigueur, la systématisation, la démarche, le cadre, l'assurance, la sérennité... ce serait dommage de passer à côté, non ? ;)

• Gab:

  Ca fait un paquet de temps que je cherchais ce qui me dérangeait dans le TDD, et j'ai enfin trouvé. Pas que je le refuse complètement, mais un truc me turlupinait, et j'ai mis le doigts dessus: quand je développe, j'aime bien tester plein de trucs (méthodes différentes pour faire la même chose). Récemment, par exemple, j'ai utilisé memcache pour cacher mes pages, puis APC, puis re-memcache, et là je mets des smarty dedans (d'où plus besoin de memcache).
  Or, si je passe mon temps à faire du test, je vais tester un truc qui en fait va disparaître au gré de mes idées, d'où frustration et perte de temps.
  Où est la faille?

• marko_:

  en effet, l'utilisation des transactions mysql avec un bloc try/catch est la meilleure solution, c'est celle que j'utilise aussi

• Hugo:

  Dans l'idéal, il faut vérifier toutes les valeurs de retour de chaque fonction utilisée, que ce soit pour les bases de données, la manipulation du système de fichier... J'utilise PDO pour mes connexions à la BDD, ce qui me permet de profiter des Exceptions pour gérer les erreurs liées à la base de données.

• Clochix:

  En sachant que l'utilisation des transactions en MySQL n'est pas toujours portable, cela dépend du moteur utilisé (ça marche pour les tables en InnoDB mais pas en MyISAM)

• J.ducastel:

  Si le concept de packages pour PHP vous intéresse, jetez un coup d'oeil à http://webappkit.net

  Il s'agit un système de paquets pour PHP, qui facilite la gestion des dépendances entre librairies et offre également une interface d'administration permettant de visualiser le tout et d'executer les tests unitaires.

  Et bien sûr, c'est open source et quelques librairies sont déjà fournies.

• Olivier Hoareau:

  Merci pour l'information sur webappkit !

  Je testerais dès que possible.

  Quelle est la particularité par rapport au système de gestion de dépendances et de packaging de PEAR ?

  Olivier

• J.ducastel:

  PEAR s'installe au niveau système et ne gère que des librairies. Webappkit s'installe au niveau application web (simple dezippage), de telle manière qu'une appli construite sur Webappkit peut être entièrement installée via FTP.

  De même, l'interface d'administration est une page web qui à terme permettra d'installer les librairies par upload de fichier zip. Pour l'instant elle permet de visualiser les tests, vérifier les dépendances, l'intégrité des paquets etc.

  En outre, les paquets sont accessibles sous forme d'objets dont la classe est extensible, et auquels on peut adjoindre des objets services issus d'autres paquets. Un paquet peut ainsi contenir d'autres types de ressource que des scripts PHP, tel que des templates, etc. Ceci permet d'avoir une application complete sous forme de paquet.

  Je ferai une nouvelle release (0.13) prochainement (une a deux semaines).

• 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 ;)

• s2pham:

  merci pour cette article, c'est intéressant de trouver des sujets qui touche le monde professionel en plus autour de PHP. Ce qui est rare.
  Mais c'est vrai qu'avoir des exemples concret c'est encore mieux. aussi je suis preneur

• Gab:

  "Le travail fait n'est jamais perdu", dixit un collègue ;)
  Tu dégage le code, mais les idées que tu as mis en oeuvre pour l'écrire reste d'une manière ou d'une autre dans ta tête.

• Martin:

  Exactement la même chose. Votre réponse est parfaite. On trouve si souvent des méthode commentées dans des classes sans savoir qui les a écrites, qui les a commentées et pourquoi... La gestion des version est là pour cela.

  Quand au wiki c'est effectivement un point intéressant pour peu que l'on en ai un sous la main.

• Raph:

  On dispose de solutions pour garder des traces de changements (svn par exemple), par contre j'ai toujours pas trouvé de solution efficace permettant de "se souvenir" de ce qui a été fait.

  Vous est-il déjà arrivé de récupérer un vieux code dont vous n'aviez la connaissance ni au moment de son écriture, ni du nettoyage ?

  Je suis persuadé que le seul cas où ça se produit c'est le coup du collègue qui dit "ya machin qui avait codé quelque chose de similaire, regarde le dépot".

• Olivier Hoareau:

  @Raph: bonne remarque, effectivement cela arrive régulièrement de commencer à développer une snippet pour nos propres besoins et de se rendre compte que quelque chose de similaire a déjà été développé dans l'équipe (par le passé, ou ... en parallèle !). Pour tenter d'endiguer ce problème je propose en règle général un ensemble de pratiques simples à mes développeurs: 1/ regarder si un "service" (par exemple technique) n'existe pas déjà dans l'API projet, 2/ ne jamais copier / coller mais plutot déplacer du code à un endroit central et l'utiliser à plusieurs endroits, 3/ toujours développer la solution la plus simple possible pour répondre au besoin du moment, entres autres.

  Eclipse et Zend Studio propose des "Code Gallery", je pense que c'est aussi une piste pour retrouver du code déjà développer en ayant une démarche "search first, code after".

• JP:

  j'aime bien cette idée de revue partielle de code, je suis cependant un peu réticent à l'idée de laisser le développeur choisir quel fragment de code sélectionner, craignant un peu la dissimulation du code "baclé" et l'envoi d'un code nettoyé, surtout si la personne relisant ce code est un n+1... Je préfère l'idée d'un envoi d'une liste des fonctionnalités développées et une revue de code "au hasard" ou d'instinct sur les fonctionnalités critiques.

  L'idée de la revue croisée est une bonne alternative, (j'en avais discuté avec Damien Seguy lors d'une formation), bien encadrée, elle permet de créer une émulsion entre les développeurs.

• Clochix:

  Merci, c'est une présentation très claire.

  Tu parles des tests fonctionnels avec Fitnesse et PHPSlim/PHPFit. Ca fait longtemps que j'en entend parler mais n'ai jamais eu l'occasion de les utiliser sur de vrais projets. Tu aurais des cas concrets de mise en œuvre à présenter ?

• Olivier Hoareau:

  @clochix: je prévois un ou plusieurs articles sur le sujet TDR (Fitnesse / GreenPepper) dans les prochaines semaines, keep in touch ;)

• 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 ?

• jacko972:

  Bonjour,

  j'ai trouvé le slide excellent. cela correspond pile poil à ce que j'aimerai mettre en place dans mon entreprise.
  ce n'est pas facile mais j'y crois dur comme fer.
  est-ce que tu as quelques conseils sur la manière de procéder ?
  merci d'avances

• Olivier Hoareau:

  @jacko972: envoie moi un email sur contact at phppro point fr en me décrivant ton contexte, tes problématiques et tes questions

• Jérémy:

  Je pense que l'apprentissage du framework est une des facettes de l'apprentissage de notre métier.
  Comme si on avait l'habitude de programme "en ligne", le jour où on décide de passe a la POO
  - il nous faut 2 mois pour comprendre les subtilité de l'héritage et utiliser les différents design pattern
  - Il nous faut 3 mois pour migrer tout le code sur php 5.3 et utiliser les namespaces (on notera que, comme pour le framework, rien nous obliger a upgrader on peut rester sur la version précédente)
  - Après 4 mois, on refait tout parce qu'on a compris comment ça marche..

  On peut trouver de exemples comparable avec la POO, des design pattern, des nouveau langages etc...

  Est ce que sur le dos de l'économie on doit stagner sur nos acquis ? je doute.

• Hervé:

  Ce qui vaut pour les framework vaut aussi pour les CMS et surtout pour Php lui même.... ;-)
  C'est toute l'histoire de l'informatique ou les choses sont rarement figées.

• Ben:

  C'est marrant parce que ça fait un moment que je développe un portail client sous drupal et je suis arrivé à la même conclusion.
  Si bien que maintenant le module drupal me sert en gros de contrôleur et que les parties Modèles et Vues sont codées séparément.

• ipatate:

  pour l'apprentissage je suis d'accord, mais c'était pareil quand j'ai appris php, actionscript etc, il y a toujours un periode d'apprentissage et puis c'est tellement bon d'apprendre une nouvelle chose. Après pour ce souvenir des class perso, il y a les commentaires !! non ??
  t'as oublié, avec un framework, il suffit de recruter un developpeur qui connait le framework pour qu'il se retrouve facilement dans le code, alors qu'avec un code sans framework ce dernier met 1 mois à comprendre comment ça marche !!

• David:

  Je suis assez d'accord avec le principe d'écrire du code le plus ré-utilisable possible mais je ne vois pas bien le lien avec le constat fait au début de l'article...

  Le temps d'apprentissage du framework est nécessaire et se révèle productif parce qu'on capitalise dessus.
  Il n'empeche que le code qu'on va développer dessus peut etre générique comme tu le dis à la fin.

  Pour la problématique de passage d'une version majeure à la suivante, c'est vrai que c'est galère, mais en même temps on ne choisit de le faire que si le projet le nécessite, c'est-à-dire si ses fonctionnalités évoluent de manière considérable. Dans le cas contraire, ce n'est souvent pas nécessaire.

  Bref, bien coder (code optimisé, réutilisable) ne dépend pas du fait d'utiliser Symfony ou ZF, ni de développer en 5.3 ou pas... Et cet article le rappelle bien !

• Sylvain:

  Pour moi la solution réside vraiment dans certains design patterns (service layer, datamapper, dao, ...) qui permettent vraiment de dissocier la logique métier du framework. J'ai récemment pu faire le test de porter directement ma couche métier de Zend Framework vers eZPublish en changeant uniquement les mappers.
  Les modèles étant très génériques, les tests unitaires sur ces classes n'ont plus à être modifiés.
  Je pense qu'en adoptant une vision très modulaire et en couches on peut vraiment palier à n'importe quelle problématique et ainsi ne plus être prisonnier d'un framework (en gros on choisit celui sur lequel on est la plus efficace)

• Hervé:

  J'aurais bien aimé lire les réponses ...

• geekbay:

  Perso, j'utilise tcpdf car il supporte le html et en général, je crée donc un tpl html que je remplis avec les données depuis la db et que je passe à tcpdf.
  Sinon pour cette technique, elle est intéressante a part qu'il me semble que si tu dois afficher un texte dont tu ne connais pas la longueur alors tu peux avoir des problèmes dans le positionnement absolu après, du style textes qui se chevauchent mais c'est à creuser.

• mojorisin:

  L'approche est interressante par contre je trouve que la génération de pdf est vraiment quelquechose de rébarbatif et peu passionnant.

  J'ai eu l'occasion d'utiliser wkhtmltopdf et cela m'a vraiment séduit :
  - avoir une approche souple de la mise en page comme on peut l'obtenir avec le (x)html / css.
  - avoir le rendu de webkit (qtwebkit)

  Le principal inconvénient de cette solution est l'obligation de pouvoir utiliser un binaire sur son hébergement.

  http://code.google.com/p/wkhtmltopd...

• JEDI_BC:

  Intéressant sauf que Zend_Pdf, même s'il peut charger des pdfs, reste encore très limité niveau fonctionnalités. Pas ou peu de formatage du texte (alignement justifié, écriture de bloc, analyse d'une syntaxe html pour le formatage), pas de possibilité de limité les actions sur le pdf comme empêcher le copier/coller ou l'impression, etc ...

  Perso j'utilise tcpdf pour générer mes pdfs de bout en bout. La librairies n'est franchement pas très propre mais est assez efficace.

• Francois:

  Nettement plus terre-à-terre, j'utilise le tandem FPDF (de http://www.fpdf.org) combiné à la libraire FPDI (http://www.setasign.de/products/pdf...).
  FPDF est une classe (géniale) qui permet de générer du PDF sans passer par des librairies et FPDI (héritant de FPDF) permet d'utiliser des modèldes comme fond de page.
  Résultat le code PHP à écrire se limite aux cellules "dynamiques"

• david:

  On peut aussi faire appel à wkhtmltopdf (http://code.google.com/p/wkhtmltopd...)
  Simple utilitaire shell pour convertir html en pdf avec webkit rendering engine.
  On peut prévoir une feuille de style dédiée.
  C'est vraiment LA solution la plus simple pour le développeur.
  Juste peut-être développer un système de cache pour les pages qui sont appelées de multiples fois.
  Je l'ai utilisé pour mon intranet Drupal (http://drupal.org/project/print). Pas encore exempt de bug avec Drupal mais ça va venir.

• Olivier Hoareau:

  Merci à tous pour vos précisions et retours d'expériences !

• Olivier Hoareau:

  @Hervé: Désolé, ce n'était pas l'objet de mon article, même si je comprends tout à fait l'intérêt que ca pourrait apporter... Qu'aurais tu répondu à ces questions ?

• Olivier Hoareau:

  @all: Merci à tous pour vos retours d'expériences très intéressant !

• metagoto:

  A la question des commandes shell, j'aurai répondu ls et cd.

  A la question "Qu'attendez vous de mon intervention ?", j'aurai répondu, avec tout autant de tact, "bah rien, c'était pas mon idée".
  ;)

• Hervé:

  Bonjour Olivier,

  Je vais répondre :

  1/ Quels OS
  Linux (Debian) pour les serveurs de prod et Windows XP pour le développement

  2/ Répartition des taches
  * développement 75%
  * tâches techniques 5%
  * réunions 5%
  * autres 5%
  * coup d'oeil par la fenêtre et passages à la cafetière 10%

  3/ Quelle est l'activité qui vous prend le plus de temps au quotidien ?
  Me lamenter sur les mauvaises pratiques de mes collègues, maudire la programmation procédurale et éviter les médisances

  4/ Les 3 logiciels les plus utilisés pour le développement
  Eclipse PDT, Firefox et SVN

  5/ L'utilité des applis Symfony
  J'en fais pas ! ;-)

  6/ Quelles sont vos douleurs actuellement pour mener à bien vos activités: ce qui vous fait perdre du temps en dev, en déploiement en prod...
  Le manque d'analyse et de spec et d'une manière générale d'informations sur ce qu'il faut faire !

  7/ Ou en êtes vous dans la roadmap produit (début, milieu, fin) ?
  ???

  8/ Votre sentiment sur la qualité du produit (d'abord du service rendu à vos clients, ensuite du code) ?
  Qualité du produit, moyen, qualité du service pas trop mal, qualité du code, nulle !

  9/ Votre niveau de connaissance dans le framework Symfony:
  -1, on ne fait que du Php pur et dur :-(

  10/ Décrivez moi comment vous vous y prenez pour : corriger un bug détecté en production, développer une nouvelle fonctionnalité planifiée, fournir le même service à un nouveau client
  Pour corriger un bug en production ... je cherche d'abord où peut se trouver le code incriminé ensuite l'auteur du bug.
  Développer une nouvelle fonctionnalité, le plus dur c'est de comprendre ce que la personne chargée du contact avec le client à retenu et compris

  11/ Quelles opérations à réaliser pour mettre en production (depuis un dev jusqu'à l'utilisation possible par un client en production ) ?
  On recherche quelque chose déja développé, par la société, ou par d'autres, on copie/colle on livre sur un FTP et voilà cher client(e), c'est à vous de tester ... on en déduira ensuite ce que vous vouliez

  12/ Donnez moi la liste des 5 ou 10 commandes en ligne de commande que vous utilisez le plus au quotidien
  Jocker

  13/ Quels sont les outils que vous avez envie d'utiliser et que n'utilisez pas encore ?
  Un framework comme Symfony

  14/ Quels sont les outils que vous ne voulez pas utiliser, ou que vous fuyez volontairement ?
  IE6

  15/ Si vous deviez utiliser un outil pour les tests unitaires ce serait ? OK pour utiliser PHPUnit pour les tests unitaires ?
  Déjà qu'on passe à la POO, on verra ensuite

  16/ Si vous deviez utiliser un outil pour le déploiement ce serait ? OK pour utiliser Phing pour le package et le déploiement, plutôt que les outils SF (trop liés à SF ?)
  ANT

  17/ Qu'attendez vous de mon intervention ?
  Un nouveau boulot, je crois..

• Yann:

  À essayer, à adopter et à ne plus jamais s'en passer : http://html2pdf.fr/

• Olivier Hoareau:

  @Hervé: Merci Hervé d'avoir pris le temps de répondre, très intéressant, et relativement proche de ce que je "croise" au quotidien chez mes clients ;)

• jpauli:

  Pas mal le questionnaire Olivier !

  On peut rapidement deviner "la moyenne" des réponses qui traduit nettement un manque de connaissances de la part de l'équipe globale du projet en ce qui concerne l'industrialisation (certains projets sont encore à 0% d'orienté objet !!)

  Qu'en est-il sur des projets similaires en Java ou encore .Net, langages réputés beaucoup plus structurants? Je pense que c'est mieux, mais qu'on trouve tout de même des irréductibles non?

  Le remède aux maux de la gestion de projets (au sens le plus large) PHP serait-il d'envoyer ses équipes faire un tour sur des projets Java/.Net ?

• mike:

  Bonjour,

  Très intéressant !
  Quel dommage que le coontenu ne soit pas proposé en PDF, tellement plus simple à conserver :-)

  D'autre part, tu es formateur indépendant ? ou ???

• mike:

  PDFlatex est une solution très souple, à envisager si vous avez la main sur les paquets installés sur le serveur :)

• fran':

  Article intéressant...

  Après être passée par fpdf, puis Zend_PDF (trop jeune à l'époque) puis Fop, j'utilise aujourd'hui Prince Xml (cf. http://www.alsacreations.com/articl...).
  C'est un binaire qui convertit une page HTML en PDF (et qui respecte Acid2).
  L'intérêt : une seule sortie HTML et 2 feuilles de style (une screen pour le navigateur et une print utilisée par princexml et/ou imprimante).
  Par contre, ce n'est pas gratuit et nécessite d'avoir la main sur le serveur (en environnement Pro, pas de problème).
  Je ne connais pas wkhtmltopdf.

• Olivier Hoareau:

  @Mike: mes clients peuvent recevoir la version originale Powerpoint ;) Je suis consultant expert et coach agile indépendant, je réalise des formations de temps en temps par l'intermédiaire de société partenaire, car je ne suis pas (encore) agréé pour ça.

• speedyop:

  merci olivier pour la formation, je suis le developpeur de ton titre ;)
  j'ai changé de boulot depuis, et dans ma nouvelle structure, hudson et eclipse sont utilisés, ta journée découverte m'a donc été fort utile.

• 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...

• NiKo:

  D'expérience la plupart des plugins Symfony sont le plus souvent des wrappers autour de lbs existantes, ou alors exploitent directement et pleinement les fonctionnalités du coeur du framework (routing, request, response, templates, orm, etc.), ce qui n'est pas toujours évident ni forcément intéressant à découpler.

  J'a très très rarement vu des libraires spécifiquement métier publiées sur la forge de plugins de Symfony, et je sais pas trop du coté des autres frameworks...

• Frato:

  Pareil que François, FPDF + FPDI. Importation d'un template en PDF, ajout des données dynamiques, et hop, un joli PDF

• spipu:

  bon, ben je ne pourrais que conseiller d'utiliser HTML2PDF http://html2pdf.fr/ étant donné que j'en suis le créateur :)