jeudi 24 juillet

Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

Articles précédents : Développeur

Liens connexes

PMO (371 hits)
L'archive version 0.10 (56 hits)
Le manuel PMO (119 hits)
Dépêche précédente (55 hits)

Dépêche modérée par

Floxy

Dépêche éditée par

Développeur : PhpMyObject 0.10 : nouvelle version

Posté par Code34 (page perso, ). Modéré le 19 octobre 2007.

La nouvelle version de PMO vient d'être publiée. PMO est une API PHP qui sert de couche d'abstraction entre le SGBD et votre application PHP en transformant les résultats renvoyés par le SGBD en objet. Le but de PMO est de limiter les actions directement sur le SGBD en travaillant sur des objets chargés en mémoire. PMO affiche d'excellentes performances qui le rendent transparent.

Cette nouvelle version 0.10 est une release majeure qui implémente de nouvelles fonctionnalités :

les exceptions
drivers pdo / postgresql / sqlite
de nouvelles méthodes

PMO s'améliore progressivement grâce aux demandes des utilisateurs. Dans ce cadre, je suis toujours à la recherche de testeurs ou de personnes qui pourraient me remonter des bugs, ou des améliorations.

NdM : PMO est un logiciel libre sous licence GPLv3

PMO (371 hits)
L'archive version 0.10 (56 hits)
Le manuel PMO (119 hits)
Dépêche précédente (55 hits)

> Lire la dépêche (25 commentaires, moyenne: 1,6).

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

PHP

Posté par Kévin FERRARE (page perso, ) le 19/10/2007 à 06:07. (lien). Évalué à 1.

Ta librairie a l'air simple et tout à fait adaptée à l'utilisation que je ferai de PHP, pour coder un site pas trop gros ou quelques scripts.

Par contre pour des applications plus complexes mieux vaut éviter ce langage, la maintenance devient rapidement horrible.

Je suis assez surpris qu'aussi peu de gens aient l'air de s'intéresser à PMO.

[^]Re: PHP

Posté par Code34 (page perso, ) le 19/10/2007 à 06:50. (lien). Évalué à 2.
Est-ce que tu peux préciser en quoi la maintenance devient horrible, parce que le but s'est justement de développer du gros site. Il y a peut être des paramètres que je n'ai pas pris en compte :D
- [^]Re: PHP
  
  Posté par Laurent J (page perso, ) le 19/10/2007 à 08:35. (lien). Évalué à 1.
  laisse tomber, on est vendredi...

[^]Re: PHP

Posté par Moun's (page perso, ) le 19/10/2007 à 20:27. (lien). Évalué à 1.

ar contre pour des applications plus complexes mieux vaut éviter ce langage, la maintenance devient rapidement horrible.

tu sais, tu peux aussi aller dire ca au mec qui a fait les skyblog ... c'est du full PHP.

Par contre, ce type est patcheur OpenBSD et a fait quelques outils que tu utilise sous linux sur des serveurs devant tenir un peu la charge.

Oui PHP a des défauts, et des gros.
Non, le plus gros probleme de PHP reste sa panoplie de bras cassés se prenant pour des warriors et qui font des trucs ingérable pleins de failles de sécu.

PMO est un bon outil, je commence à m'amuser un peu avec et j'ai quelques projets qui pourront en avoir besoin.
- [+] [^]Re: PHP
  
  Posté par alpage (Jabber id, page perso, ) le 20/10/2007 à 12:39. (lien). Évalué à -1.
  En même temps, skyblog, c'est pas vraiment complexe comme appli. Wikipedia par contre...
  - [^]Re: PHP
    
    Posté par Laurent J (page perso, ) le 22/10/2007 à 14:18. (lien). Évalué à 2.
    Toi tu n'as pas dû participer au developpement d'une plateforme de blog pour dire ça...
    
    Je cotoie quasie quotidiennement (par IRC) les développeurs d'Overblog (une autre plateforme de blog), et de temps en temps ceux de Skyblog, et je peux t'assurer que ce genre d'application, ça ne se résume pas à afficher du texte qui est dans une BD. Il y a quand même énormément de choses à développer. C'est d'autant moins simple que ce genre d'applications ont plusieurs centaines de milliers d'utilisateurs, et donc où la prise en compte de la sécurité et des performances est primordiale. Ce qui ne facilite pas le développement, et nécessite des compétences d'experts.
    
    Tiens, pour t'en convaincre, regarde un peu le code de dotclear 2 (qui peut être utilisé pour faire une plateforme de blog)
    
    Et puis pour finir, un blog, ce n'est rien qu'un CMS spécialisé, tout comme l'est Mediawiki. Donc niveau complexité, à fonctionnalité équivalente (en terme de gestion de droit, de commentaire, d'édition etc..) ça se vaut...
- [^]Re: PHP
  
  Posté par lfmarante (page perso, ) le 20/10/2007 à 13:48. (lien). Évalué à 2.
  Sans parler des inconsistance de l'API comme l'abscence de standardisation des noms de fonctions, le plus gros problème de PHP reste surtout son manque total de rigueur, et que tu sois développeur OpenBSD n'y change rien.
  Tout programmeur fait des erreurs et PHP en laisse beaucoup passer silencieusement.
  Par exemple lors d'un changement de nom de variable, le langage ne détectera pas si tu oublies d'en renommer une à un endroit et le programme va produire des résultats bizarres parfois sans crasher ou alors seulement sous certaines conditions ... passer des heures à chasser ce genre de bugs qui auraient pu été détectés automatiquement est assez frustrant et contre-productif.
  
  On pourrait s'étendre des heures sur les inconvénients dus à l'absence de déclaration des variables ou de typage, ou encore sur l'absence de nécessité de catcher les exceptions mais ce n'est pas le sujet.
  
  Personnellement je pense que développer en PHP c'est plus facile pour un programmeur débutant parce qu'on est plus libre de coder sans se faire tout le temps taper dessus par l'interpréteur, mais il faut voir le temps qu'on perd à chasser les bugs que n'importe quel compilateur d'un langage rigoureux aurait pu détecter.
  - [^]Re: PHP
    
    Posté par alpage (Jabber id, page perso, ) le 20/10/2007 à 20:56. (lien). Évalué à 1.
    Le point que tu soulèves ici concerne n'importe quel langage dynamique : certains problèmes n'apparaissent qu'à l'exécution. C'est aussi vrai pour Ruby, Python, etc. A cela on réponds généralement qu'avec une suite de tests ayant une couverture raisonnable, ce genre de problème est rapidement détecté. Après je n'ai aucune expérience sur PHP, si effectivement le "programme va produire des résultats bizarres parfois sans crasher ou alors seulement sous certaines conditions", c'est une autre histoire...
    
    D'autre part, le typage explicite des variables, si il permet effectivement de détecter assez tôt des erreurs simples, ne met pas à l'abri de bugs subtils à l'exécution. C'est particulièrement vrai avec C/C++, mais même en Java, on est pas à l'abri d'une NullPointerException...
    - [^]Re: PHP
      
      Posté par Antoine () le 20/10/2007 à 23:40. (lien). Évalué à 4.
      Le point que tu soulèves ici concerne n'importe quel langage dynamique : certains problèmes n'apparaissent qu'à l'exécution.
      
      Non ça n'a rien à voir. On parle ici de typage fort, d'absence de conversions implicites délirantes, d'interdiction d'utiliser une variable non-initialisée, etc.
      
      Quelques comparaisons bien senties...
      
      Python :
      >>> 1 + "a"
      Traceback (most recent call last):
      File "", line 1, in
      TypeError: unsupported operand type(s) for +: 'int' and 'str'
      >>> x + 1
      Traceback (most recent call last):
      File "", line 1, in
      NameError: name 'x' is not defined
      >>> x = 0; print x[1]
      Traceback (most recent call last):
      File "", line 1, in
      TypeError: 'int' object is unsubscriptable
      
      PHP :
      <?php echo 1 + "a"; ?>
      1
      <?php echo $x + 1; ?>
      1
      <?php $x = 0; echo $x[1]; ?>
      - [^]Re: PHP
        
        Posté par Code34 (page perso, ) le 21/10/2007 à 08:35. (lien). Évalué à 2.
        Il y a d'autres exemples
        
        tiré de la doc php
        echo($foo = 5 + "10 cochonnets";)
        affiche 15
        
        pour mieux comprendre l'évaluation
        echo($foo = 5 + "string 10 cochonnets";)
        affiche 5
        
        C'est aussi ça qui a fait le succès de PHP. Que l'interpréteur soit tolérant à certaines aberrations, et qu'on puisse opérer sur différents types de variables sans caster explicitement. Le typage n'étant pas un concept évident pour les développeurs débutants qui voulaient seulement faire une page web (..)
        
        Depuis les besoins ont évolués. Je suis du même avis que toi, l'idéal serait un typage plus fort, la déclaration explicite des variables, une normalisation des noms des fonctions, etc ... et pourquoi pas du tout oo. C'est d'ailleurs vers ça que tend la version 5 qui a apporté quand même pas mal de choses.
        
        En même temps, d'autres langages oo que je ne citerais pas ici pour ne pas effrayer les adeptes du kernel linux sont beaucoup évolués sur ces critères ;)
        
        [^]Re: PHP
        
        Posté par Kévin FERRARE (page perso, ) le 21/10/2007 à 13:56. (lien). Évalué à 0.
        
        Depuis les besoins ont évolués. Je suis du même avis que toi, l'idéal serait un typage plus fort, la déclaration explicite des variables, une normalisation des noms des fonctions, etc ... et pourquoi pas du tout oo.
        
        Ca existe déja et ca s'appelle java ou python ça :)
        Encore que j'aurai tendance à préférer Java pour sa meilleure gestion des exceptions, son typage explicite et sa rapidité (sans parler des librairies comme GWT / Echo2 qui rendent le développement web bien plus simple ou de hibernate qui est un plaisir à utiliser pour les bdd)
  - [^]Re: PHP
    
    Posté par Erwan (page perso, ) le 21/10/2007 à 19:05. (lien). Évalué à 0.
    C'est vrai que dans la pratique PHP est facile pour les debutants (pour les raisons que tu donnes), mais a mon avis c'est plus adapte pour les developpeurs qui savent ce qu'ils font.
    
    Un debutant qui passe du temps sur PHP va attraper de tres mauvaises habitudes (genre ca marche pas, j'essaye de bidouiller ici et la et quand ca marche je suis content). Au contraire, quelqu'un d'experimente pourra se forcer a la rigueur (avec du code bien organise et des tests unitaires) et pourra profiter des avantages de PHP:
    - un bon nombre de bibliotheques
    - le probleme de faire passer un site PHP a l'echelle ("scalability") a ete resolu par beaucoup de gens, donc on sait comment faire.
    
    C'est probablement pour ca que de gros sites comme Flickr, Facebook, et la plupart des sites de Yahoo sont codes en PHP.
    
    Le principal probleme de PHP c'est que c'est pas un "langage cool", mais c'est un petit langage pas beau qui permet de faire ce qu'il y a a faire ("gets the job done").
    - [^]Re: PHP
      
      Posté par Antoine () le 21/10/2007 à 19:18. (lien). Évalué à 1.
      Au contraire, quelqu'un d'experimente pourra se forcer a la rigueur (avec du code bien organise et des tests unitaires) et pourra profiter des avantages de PHP:
      - un bon nombre de bibliotheques
      - le probleme de faire passer un site PHP a l'echelle ("scalability") a ete resolu par beaucoup de gens, donc on sait comment faire.
      
      Je sais pas moi, mais un langage comme Python a probablement plus de bibliothèques que PHP, il est à la fois plus puissant et plus rigoureux, et je ne pense qu'on puisse plus prétendre qu'il est moins, heu, "scalable" pour faire des sites Web. Franchement, PHP c'est le langage où il faut encore passer par des outils tierce partie pour mettre en cache le bytecode des fichiers sources...
      
      (de toute façon en matière de performances de sites Web dynamiques la meilleure chose à faire est de prévoir un cache quasi-statique)
      - [^]Re: PHP
        
        Posté par Erwan (page perso, ) le 22/10/2007 à 03:49. (lien). Évalué à 2.
        Oui, Python est un tres bon langage pour faire des sites web scalables. Le probleme de la "scalability" est d'ailleurs assez different du probleme des performances.
        
        Je disais plutot ca par rapport a des langages plus jeunes, ou moins courament utilises, ou encore certains frameworks qui permettent d'impressionner ses amis en quelques minutes mais sont difficile a faire monter en charge. Par exemple, si tu fais un site avec Rails, c'est tres sympa les active records mais le jour ou tu dois avoir plusieurs machines front-end et plusieurs machines DB, c'est nettement moins trivial a faire que si tu avais ecrit toi-meme ta couche de stockage de donnees en attaquant directement un SGDB.
        
        Evidement il n'y a pas une seul langage magique qui sert a tout. J'aime beaucoup Python, et quand je peux l'utiliser je le fais; mais recement j'ai eu une appli Facebook a developper. J'aurais pu utiliser Python mais la seule bibliotheque Facebook en Python est non-officielle, incomplete et pas vraiment maintenue. Alors j'ai choisi en PHP, langage de la bibliotheque officielle et qui est reference dans toutes leurs docs. Ben oui, Facebook est ecrit en Python alors ils sont capables d'ecrire une bonne bibliotheque!
        
        Tout ca pour dire que quand on demarre un projet il faut savoir regarder toutes les possibilites, et eviter de choisir le langage "qu'on aime bien" ou qui est a la mode. Pour ca il faut garder l'esprit ouvert, et ne pas se cantonner a son langage prefere.
        
        [^]Re: PHP
        
        Posté par Antoine () le 22/10/2007 à 16:35. (lien). Évalué à 3.
        Tout ca pour dire que quand on demarre un projet il faut savoir regarder toutes les possibilites, et eviter de choisir le langage "qu'on aime bien" ou qui est a la mode. Pour ca il faut garder l'esprit ouvert, et ne pas se cantonner a son langage prefere.
        
        Tout à fait. Ceci dit, ayant programmé plusieurs années en PHP ainsi qu'en Python, je vois très peu d'avantages à PHP si ce n'est sa disponibilité chez les hébergeurs et les quelques fonctionnalités liées au cloisonnement des instances (open_basedir etc.).

Requete SQL Mysql / Postgresql

Posté par tfeserver tfe (page perso, ) le 19/10/2007 à 07:40. (lien). Évalué à 1.

Salut,

J'ai lu dans ta doc que tu permettais d'executer directement des requetes sql via $controler->queryController($query)

Cependant les requetes sql peuvent etre differentes selon le sgbd: IE le limit/offset de mysql/postgresql.
Comment fais-tu pour gérer cela? tu converties la requête selon le driver?

[^]Re: Requete SQL Mysql / Postgresql

Posté par Code34 (page perso, ) le 19/10/2007 à 07:59. (lien). Évalué à 1.
En fait, il n'y a pas besoin de convertir la requête SQL, celle-ci est envoyé tel quel au SGBD.

PMO traite les résultats renvoyés par le SGBD

Cela implique que si tu souhaites changer de SGBD du jour au lendemain, il faudra réécrire tes requêtes SQL pour les adapter à l'implémentation SQL du SGBD.
- [^]Re: Requete SQL Mysql / Postgresql
  
  Posté par dguihal () le 19/10/2007 à 13:25. (lien). Évalué à 5.
  Ca limite quand-même grandement l'intérêt de PMO alors
  - [^]Re: Requete SQL Mysql / Postgresql
    
    Posté par Code34 (page perso, ) le 19/10/2007 à 13:46. (lien). Évalué à 1.
    Il est possible facilement de rajouter un mapper qui construirait les SELECT (car ça ne concerne que les SELECT) mais cela poserait des problèmes plus important que ça n'en résoudrait:
    
    La plus part des problèmes de perfs sont liés à des requêtes sql mal écrites, ici le dev reste maitre de la requête passé au SGBD
    
    De plus, tu ne changes pas de SGBD tout les jours
    
    Et en dernier lieu, c'est pas le rôle de PMO d'implémenter des rustines pour corriger les implémentations exotiques du langage SQL des SGBD du marché ;)
    - [^]Re: Requete SQL Mysql / Postgresql
      
      Posté par dguihal () le 19/10/2007 à 14:14. (lien). Évalué à 3.
      Il est évident que si tu ne considère que le point de vue des performances alors effectivement ta solution est bonne.
      
      Par contre, pour moi, l'intérêt d'une abstraction au SGBD c'est justement de pouvoir changer à moindre frais de SGBD. Alors pour un projet perso ou jetable effectivement tu ne changes pas de SGBD tous les jours, par contre sur un projet de type CMS une abstraction totale de type hibernate ( http://www.hibernate.org/ en java ) est pour moi plus intéressant car tu n'impose plus un SGBD à ton appli.
      - [^]Re: Requete SQL Mysql / Postgresql
        
        Posté par Code34 (page perso, ) le 19/10/2007 à 14:39. (lien). Évalué à 1.
        Effectivement, c'est un point à améliorer.
        
        Je pense que la couverture totale de l'abstraction se fera dans la roadmap en 0.12 en même temps que la gestion des alias.
        
        [^]Re: Requete SQL Mysql / Postgresql
        
        Posté par Antoine Bonnefoy (page perso, ) le 20/10/2007 à 00:03. (lien). Évalué à 1.
        En même temps, 90% des requêtes utilisées par un site web standard sont communes a tous les SGBD.
        
        Pour les autres, elle sont surtout de la manipulation de chaînes de caractères. Mais on trouve des comparatifs entre les bases comme celui-ci qui me sert beaucoup:
        http://fadace.developpez.com/sgbdcmp/fonctions/
        
        [^]Re: Requete SQL Mysql / Postgresql
        
        Posté par Code34 (page perso, ) le 20/10/2007 à 18:10. (lien). Évalué à 1.
        je vais étudier le problème . Le but n'est pas de réimplémenter pour chaque SGBD un mappage vers les fonctions.
        
        Je pense que la solution actuelle est la plus simple. Est-ce que hibernate mappe toutes les fonctions ?

Yet Another Object-Relational Mapping (ORM)

Posté par cellophane () le 21/10/2007 à 10:54. (lien). Évalué à 3.

Il serait intéressent de situer ce projet par rapport aux autres existants :
http://en.wikipedia.org/wiki/List_of_object-relational_mappi(...)

Au fond, quel est l'intêret d'utiliser ce framework :
- Sa simplicité au vu ce certains autres ORM ?
- Sa rapidité ?
- Sa documentation en francais ?

[^]Re: Yet Another Object-Relational Mapping (ORM)

Posté par Code34 (page perso, ) le 21/10/2007 à 15:31. (lien). Évalué à 2.
Voici les points qui diffèrent avec les autres ORM existant.

PMO est plus jeune, et je suis seul à bosser sur le projet.

PMO est une api. Il couvre une infime portion de ce que couvre les frameworks comme Zend, Cake, symphony. En ce sens, PMO pourrait très bien faire parti d'un des frameworks cité précédement pour améliorer la couche modèle de mvc.

Toutes les classes de PMO implémentent des interfaces. (ca semble évident mais les ORM qui datent de php4, héritent aussi des lacunes des architectures conçues au fil de l'eau sans interface.

Cela rend PMO facilement extensible (j'ai mis moins d'une heure pour développer le driver postgresql), facilement implémentable dans d'autres projets et cela permet aussi de remplacer des composants de PMO par des composants plus performants.

PMO est runtime. Il n'y a pas besoin de déclarer des schémas de bdd dans des fichiers xml. PMO s'adapte automatiquement aux schémas des BDD. En gros, en quelques minutes (en survolant le manuel), tu peux déjà manipuler les éléments de ta BDD.

PMO te permet de garder le contrôler sur la requête SQL qui est passé au SGBD. Cela est une faiblesse comme on en a discuté dans le post au dessus, mais aussi un point fort. Ca permet au développeur de savoir ce qui se passe.

En gros, simplicité, performance.

Revenir en haut de page

Articles précédents : Développeur

Liens connexes

Dépêche modérée par

Dépêche éditée par

Développeur : PhpMyObject 0.10 : nouvelle version

PHP

[^]Re: PHP

[^]Re: PHP

[^]Re: PHP

[+] [^]Re: PHP

[^]Re: PHP

[^]Re: PHP

[^]Re: PHP

[^]Re: PHP

[^]Re: PHP

[^]Re: PHP

[^]Re: PHP

[^]Re: PHP

[^]Re: PHP

[^]Re: PHP

Requete SQL Mysql / Postgresql

[^]Re: Requete SQL Mysql / Postgresql

[^]Re: Requete SQL Mysql / Postgresql

[^]Re: Requete SQL Mysql / Postgresql

[^]Re: Requete SQL Mysql / Postgresql

[^]Re: Requete SQL Mysql / Postgresql

[^]Re: Requete SQL Mysql / Postgresql

[^]Re: Requete SQL Mysql / Postgresql

Yet Another Object-Relational Mapping (ORM)

[^]Re: Yet Another Object-Relational Mapping (ORM)