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
Aller plus loin
# PHP
Posté par timid . Évalué à 1.
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 (site web personnel) . Évalué à 2.
[^] # Re: PHP
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: PHP
Posté par Mouns (site web personnel) . Évalué à 1.
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 rhizome . Évalué à -1.
[^] # Re: PHP
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
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 . Évalué à 2.
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 rhizome . Évalué à 1.
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 . Évalué à 4.
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 (site web personnel) . Évalué à 2.
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 timid . Évalué à 0.
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 . Évalué à 0.
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 . Évalué à 1.
- 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 . Évalué à 2.
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 . Évalué à 3.
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 (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 5.
[^] # Re: Requete SQL Mysql / Postgresql
Posté par Code34 (site web personnel) . Évalué à 1.
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 . Évalué à 3.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 3.
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 (site web personnel) . Évalué à 2.
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.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.