PHPPRO

Commentaires récents

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

• avetis.kazarian:

  Je ne pense pas que dirname( __FILE__ ) remplace le define( 'ROOT' , <dir> ).

  L'un n'a rien avoir avec l'autre.

  L'utilisation d'une constante qui pointe sur la racine est très utile : pour former un path sans avoir de ROOT, on doit jongler avec les '/..' etc.

  L'inclusion dans les autoloader de class (spl_autoload_register), de déplacement au sein du filesystem du code, etc., sont entièrement facilités par une constante "ROOT". Les chemins relatifs portent trop souvent à confusion.

  De plus, le fait de définir le ROOT à partir de dirname( __FILE__ ) fait qu'il est absurde de dire une bêtise comme :

  "Plus besoin de tenir un fichier de configuration avec des define qui est a modifié à chaque installation."

  Encore une fois, l'un et l'autre sont deux choses différentes.

  De plus, il aurait été intéressant de préciser qu'à partir de la version 5.3, la constante __DIR__ offre l'équivalent d'un dirname( __FILE__ );

• Olivier Hoareau:

  @avetis.kazarian: tout est histoire de pratique, il n'y pas de bonnes et mauvaises pratiques universelles, cependant certaines pratiques sont plus adaptées que d'autres dans certaines situations.

  Un fichier qui utilise le principe de dirname(__FILE__) pour inclure ses dépendances, est potentiellement utilisable directement par une autre application ou script, si il nécessite la présence de constantes (ex: ROOT) alors il faudra au préalable définir ces constantes avant d'utiliser ce fichier dans une autre application.

  Effectivement, cela n'a pas de réelle importance lorsque l'on développe une application autonome, mais en prend lorsque l'on décide de rendre potentiellement mutualisable à toutes nos applications/scripts tous les développements que nous réalisons.

  Attention aux "dépendances" implicites de notre code à des éléments extérieurs (define, variable globales, fichiers de configuration...) ils rendent difficilement testable ou utilisable dans un autre contexte notre code.

  Merci pour la précision sur la constante __DIR__ en PHP 5.3, pour toutes les applications legacy des S.I français (et autres !) qui ne pourront pas bénéficier de la 5.3 avant quelques mois voir années, dirname(__FILE__) reste utilisable en attendant...

• 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

• spm:

  Merci, c'est un article interessant pour un sujet qui est d'actualité pour moi. Comment inserer des images dans un documents docx ?

• Olivier Hoareau:

  @spm: C'est un peu plus compliqué mais possible, j'utilise ce type de routine (qui contient certainement des bugs, mais qui fonctionne pour mes générations de rapports avec OpenXML) :

  // parses for pics
  if (preg_match_all('/(.*)<\/p\:pic>/U',$content,$matches)>0) {
  for($i=0;$i/U',$matches[1][$i],$matches2)>0){
  $matches3 = null;
  if(preg_match_all('/\$\{([^\}]+)\}/',$matches2[3][0],$matches3)>0) {
  $matches4 = null;
  if(preg_match_all('/0){
  $relFile = dirname($file).'/_rels/'.basename($file).'.rels';
  if (true === file_exists($relFile)) {
  $x = simplexml_load_file($relFile);
  foreach($x->Relationship as $relationship){
  if ((string)$relationship['Id'] === $matches4[1][0]){
  $picFile = (string)$relationship['Target'];
  if(!$picFile) continue;
  $picFile = realpath(dirname($file).'/'.$picFile);
  if(!$picFile) continue;
  unlink($picFile);
  try {
  $tplPicFile = $this->parseVar($matches3[0][0],$matches3[1][0],$vars);
  } catch(Exception $e) {
  $tplPicFile = dirname(__FILE__).'/resources/no-data.png';
  }
  copy($tplPicFile,$picFile);
  }
  }
  }
  }
  }
  }
  }
  }
  $content = $this->parseString($content,$vars);
  

  Globalement, je mets le nom de la variable dans l'attribute "description" texte de l'image dans mon document openxml (par exemple dans powerpoint) puis je parse le xml du document pour remplacer les occurences des variables par les vrais images sachant que les balises xml existent déjà (puisque créé par powerpoint) sauf sont à ajouter les balises xml des resources (le fichier image complémentaire)

  Sorti du contexte, ca doit être un peu rebutant par contre, je le conçois...

  olivier

• metagoto:

  Est-ce qu'on peut dire que c'est du cloud computing ?

• syndrael:

  Pour ma part, j'aurais séparé PHP et MySQL, cela permettra de créer si besoin un cluster en fonction de la charge à prévoir.
  Je n'ai pas compris cette notion de Serveur Mandataire, ça ne peut pas être fait par le serveur Web ou PHP ?
  Le reverse-proxy est à mon sens géré par l'hébergeur, donc techniquement je n'en parlerai pas dans la réponse. Et puis au final je ne parlerai même pas de PHP ou de MySQL, car pour ton client qui n'a pas de ressource technique ni peut-être de connaissance cela ne lui dit rien.
  Par contre, il faudrait accès ton discours autour du gain apporté..
  Qu'en pensent les autres ??
  Bonne journée
  S.

• Olivier Hoareau:

  @metagoto: d'après la définition Wikipédia (et celle que j'avais en tête), il ne s'agit pas vraiment de cloud computing, car dans ce cas là le client est "propriétaire" de l'infrastructure et doit gérer le capacity planning notamment. Source: http://fr.wikipedia.org/wiki/Cloud_computing

  @syndrael: Bonne remarque concernant la séparation PHP/MySQL. Je n'ai pas jugé utile de le faire dans cette version de la plateforme car nous prévoyons des volumétries relativement modestes, et le client souhaite pouvoir maintenir ou faire maintenir l'application et la plateforme par des partenaires plutôt web agency dans le futur (boite locale). Concernant le reverse-proxy, j'aurais effectivement pu utiliser les mécanisme de load balancing proposé par l'hébergeur (optionnel, pas dispo en standard), je souhaitais avoir un peu plus de flexibilité et pouvoir brancher mon propre monitoring. Concernant le gain apporté, je ne vous ai pas publié la propale ;) mais elle était suffisamment fourni sur ces aspects. Merci pour tes retours !

• Jonas:

  Je serait curieux de savoir quel logiciel vous avez utilisé pour faire les schémas. Dia ou autre ?

  Merci.

• Olivier Hoareau:

  @Jonas: J'ai utilisé Powerpoint v2007 ;)

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

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

• Vincent:

  Bonjour,

  Je suis en train de faire ce type de manipulation avec du code un peu différent selon mon besoin.

  Je rencontre un problème au niveau de la compression. j'utilise bien ZipArchive et je change l'extension de zip par pptx mais openOffice me demande de choisir un filtre pour l'ouvrir...chose qui n'arrive pas avec un fichier fais par PowerPoint et quand j'en choisi un il me fais une erreur. Dans l'archive il y a bien tous les dossiers et fichiers ! pourriez vous m'aidez s'il vous plait ?