Cher journal,
La v0.06 à peine publiée, une nouvelle version 0.07 de PMO vient de sortir. Je vous invite à faire des tests dès maintenant: Celle-ci intègre des améliorations assez significatives pour justifier l'existence de ce journal.
Un article qui décrit les nouveautés, et les benchs de cette v 0.07
http://pmo.developpez.com/versions/0.07/
L'url vers le manuel:
http://pmo.developpez.com/manuel/
Le site officiel:
http://pmo.developpez.com/
Journal PMO v 0.07 déjà
29
juil.
2007
# Pour ceux qui ne saurait pas ...
Posté par epot (site web personnel) . Évalué à 10.
C'est plus clair comme çà, non ? Ou la description était volontairement omise pour augmenter le nombre de hits sur la page ? ;-)
# Mmmm, voyons voir...
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 4.
C'est encore une PHPèterie salement gorête, quoi...
[^] # Re: Mmmm, voyons voir...
Posté par rhizome . Évalué à 2.
$controler = new MyControler();
$map = $controler->queryControler("SELECT * FROM utilisateur;");
$object = $map->getObjectByValue("utilisateur", "login", "ancienlogin");
$object->setAttribute('login','nouveaulogin');
$controler->commitControler($object->getId());
Pourquoi cette classe MyControler ? Est-ce qu'on ne peut pas encapsuler ça dans l'objet qui représente la donnée ? (btw controller prends deux L)
Ensuite on doit taper une requête SQL pour simplement récupérer tous les enregistrements !? On peut pas éviter ça ? C'est censé être un ORM quand même. Qu'on permette l'utilisation de SQL pour des clauses d'agrégats ou des appels de procédures stockées par exemple, c'est bien, mais pour juste faire ça, je ne veux pas taper de SQL.
Ensuite si je comprends bien le getObjectByValue va récupérer un enregistrement donné d'après la colonne login ? Pourquoi avoir chargé tous les utilisateurs alors ? SI j'ai 10 000 utilisateurs, on va tous les les récupérer depuis la bdd à chaque fois que je veux modifier un login, construire une structure de données puis filtrer les résultats ?
Ensuite on fait la modification du l'attribut, ne peut-on pas avoir une syntaxe plus légère du genre $object->setLogin('nouveaulogin');
Enfin le commit, et cette fameuse classe MyController dont je ne vois pas l'utilité en tant qu'utilisateur de ta lib. Et en plus je dois lui passer un id, alors qu'on sait déjà sur quel objet on travaille. Que ce controller te soit utile en interne OK, mais moi je ne veux pas m'en préoccuper, je veux juste mettre à jour un login.
Voici à quoi pourrait ressembler l'API :
$user = Utilisateur::getByLogin("ancienLogin");
$user->setLogin("nouveaulogin");
$user->commit();
Sinon faire son auto-promotion dans Wikipedia je suis pas sur que ce soit de très bon goût ;)
[^] # Re: Mmmm, voyons voir...
Posté par Code34 (site web personnel) . Évalué à 2.
la réponse dans un fichier texte ici:
http://code34.girafon.org/reponse.txt
[^] # Re: Mmmm, voyons voir...
Posté par Bruno Michel (site web personnel) . Évalué à 1.
fonctionnement des versions antérieures. Le controler a évolué.
Tu peux te référer au manuel qui est à jour:
http://pmo.developpez.com/manuel/
Pour répondre à ta question concernant SQL
PMO tout comme PDO n'est pas la pour se substituer au langage SQL. PMO se
concentre donc sur son rôle crée une couche d'abstraction objet entre le sgbd,
et l'application.
La méthode getObjectByValue peut récupérer un Objet (et non enregistrement car
il embarque des méthodes) en fonction de l'attribut que tu désignes en
paramètre. Ca peut être login si t 'as une table utilisateur avec une colonne
login, tout comme ça peut être nomproduit si t'as une table produit, ou même
age si t'as une table personne etc ... PMO découvre le schéma de tes tables
dynamiquement, tu as donc des méthodes génériques.
Le nombre d'objets que tu crées en mémoire, dépend de l'optimisation de ta
requête. Si tu as une table avec 10000 enregistrements et que tu fais un
select * sans critère forcément tu auras un nombre d'objets ultra importants.
Et c'est clairement pas une bonne idée, si tu veux juste modifier un login ..
Par contre si tu fais un select * from utilisateur where login="toto"; t'auras
qu'un seul objet à manipuler ;) Les contraintes sont les même qu'avec un
mysql_fetch_row hormis que tu manipules des objets.
Pour le nommage setLogin, non étant donné que cette méthode est spécialisé à
une colonne login, alor que setAttribute te permet de manipuler n'importe
quelle colonne.
Pour le $user->commit(), cela fait justement parti des dernières évolutions
comme $user->delete();
Si t'es vraiment interressé pour soumettre des évolutions, n'hésite pas à me
contacter sur mon mail perso, ou sur la liste de diffusion google du projet.
Jusqu'à maintenant j'ai essayé d'implémenter tout ce qu'on m'a soumis.
[^] # Re: Mmmm, voyons voir...
Posté par Bruno Michel (site web personnel) . Évalué à 1.
[^] # Re: Mmmm, voyons voir...
Posté par Code34 (site web personnel) . Évalué à 0.
[^] # Re: Mmmm, voyons voir...
Posté par rhizome . Évalué à 1.
Le code que j'ai cite provient du lien que tu as donne et que tu viens de mettre a jour en vitesse.
Si on decouvre le shema, pourquoi ne pas creer dynamiquement des methodes specifiques ? D'ailleurs, quel est l'interet de cette decouverte de schema puisqu'on fournit les informations de shema a tes methodes generiques lorsqu'on les appelle ? Ce que je propose, c'est que lorsque pmo decouvre un champ login, il ajoute les methodes setLogin et getLogin, si le champ s'appelle age, il cree setAge et getAge et ainsi de suite...
Sinon, je ne comprends pas l'interet de getObjectByValue puisqu'on doit de toute facon passer les criteres de selection a la requete SQL.
[^] # Re: Mmmm, voyons voir...
Posté par Code34 (site web personnel) . Évalué à 1.
J'ai bien compris alpage ce que tu souhaitais. Depuis hier, soir on manipule directement les objets de cette façon:
$object->login="toto";
echo($object->login); // affiche toto
j'ai implémenté les magiques qui dérrière font appel à setAttribute et getAttribute
getObjectByValue sert à manipuler ta map d'objet
Tu auras peut etre besoin de récupérer 100 objets et ensuite envie de les manipuler de façon non séquentielle.
[^] # Re: Mmmm, voyons voir...
Posté par herodiade . Évalué à 2.
Un exemple de motif de conception en vogue en ce moment : http://fr.wikipedia.org/wiki/Active_record_%28motif_de_conce(...)
Déjà plusieurs fois implémenté en PHP, par exemple ici : http://phplens.com/lens/adodb/docs-active-record.htm
C'est un bon exemple : John Lim a une remarquable expérience en la matière, tu peut t'en inspirer, et peut-être aussi utiliser sa bibliothèque ADOdb pour bénéficier d'une abstraction sur l'accès au moteur SGBD, donc d'une meilleure portabilité (parce que MySQL, c'est bien, mais il existe d'autres morteurs de bados (comment ça, "sqlite roxor" ? :P)).
[^] # Re: Mmmm, voyons voir...
Posté par Code34 (site web personnel) . Évalué à 1.
IL FAUT LIRE LES DOCS + les PHPDOCS dans l'archive , ça m'évite aussi de reexpliquer, 50 fois la meme chose. PMO implémente par exemple active record, et fait même plus que cela car il permet d'utiliser le polymorphisme, ou des maps ;)
PMO est plus souple que ADOdb (si tu ne comprends pas pourquoi, je t'invite à tester les 2), et les autres ORM PHP car c'est une API qui se concentre sur l'abstraction objet et non un framework qui va faire tout et n'importe quoi.
PMO utilise PDO en couche d'abstraction, il permet donc d'utiliser Oracle, interbase, postgrsql, mysql ...
[^] # Re: Mmmm, voyons voir...
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 4.
dynamiquement, tu as donc des méthodes génériques.
Donc, à chaque page servie, PMO doit réapprendre ce qu'il à découvert quatre secondes plus tôt ?
Si tu as une table avec 10000 enregistrements et que tu fais un select * sans critère forcément tu auras un nombre d'objets ultra importants.
10000 lignes, c'est une petite table, très petite même.
Les contraintes sont les même qu'avec un mysql_fetch_row hormis que tu manipules des objets.
Sauf que le mysql_fetch_row, c'est juste de la plomberie de transfert de données. Le vrai travail se fait en amont, lors de la conception des tables et de l'écriture des requètes, vues et autres procédures stockées...
[^] # Re: Mmmm, voyons voir...
Posté par Code34 (site web personnel) . Évalué à 1.
Ce temps de découverte du schéma de la table via un DESC est beaucoup plus infime que s'il avait à accéder à un fichier xml en lecture ecriture + parsing comme les autres ORM.
Au niveau des 10 000 lignes cela ne change rien, ta table peut également stocker 1 000 000 d'enregistrements.
C'est l'optimisation de ta requête SQL qui est importante, et ça il n'y a que toi qui peut le faire.
PMO est une couche d'abstraction objet c'est aussi de la plomberie, c'est sur que ça n'est pas aussi bien que si c'était un module PHP à part entière car il utilise d'autres couches d'abstraction en dessous .
[^] # MultiDeskOS inside
Posté par herodiade . Évalué à 2.
ORM signifie « Object Relation Mapping » : le but est avant tout d'abstraire les relations entre les objets. S'ils s'agissait seulement de saupoudrer les noms de tables et colonnes d'une pincée de syntaxe objet-like, on aurait surement appelé ça OTR (comme object table mapping).
Pour rester dans les exemples bateau, imagine que j'ai une entité "Utilisateur" et une entité "Addresse" (un Utilisateur ayant une seule Addresse, pour
faire simple). Je souhaite évidement pouvoir faire des choses du type :
$user = Utilisateur::getByName("Mickael Kael");
$user->address->setTown("Muflin");
$user->save();
Dans cet exemple on voit comment la relation pourrait être "abstraite" de la couche de persistance. En outre on aimerais pouvoir charger paresseusement (lazy loading) les objets et leurs attributs. Surtout lorsqu'on va sélectionner en profondeur (ex. ne pas charger toute les tables traversées (en plus, a coups de "SELECT *" !) en mémoire lorsqu'on fait un $user->client->address->town->getPostcode() sur un objet précis alors que pour ses congénères on n'utilise que $user->getClient()).
Si j'ai bien compris, pour le moment, l'utilisateur doit gérer ces relations à la main en écrivant ses requêtes et en agrégeant/associant manuellement les objets d'une même « ligne » (sic) du tableau MyMap, et en moulinant à l'ancienne pour reconstruire les liens en deréférençant les fkeys. Mais alors, quel intérêt d'un ORM (ou même, d'une vue objet) ?
> Le design pattern de pmo est documenté
J'ai lu le manuel indiqué en lien dans le journal (ici c'est culture Unix, alors si le man ne documente pas tout et qu'il faut lire des divx pour connaitre l'API...), mais je crois que tu n'avais pas compris mes remarques.
> PMO implémente par exemple active record, et fait même plus que cela [...]. PMO est plus souple que ADOdb [...] et les autres ORM PHP car c'est une API qui se concentre sur l'abstraction objet et non un framework qui va faire tout et n'importe quoi.
Et sinon ça va les chevilles ?
> PMO utilise PDO en couche d'abstraction, il permet donc d'utiliser Oracle, interbase, postgrsql, mysql
Ce que je voulais dire, c'est qu'ADOdb offre une API permettant de s'affranchir des petites différences de syntaxe SQL entre les divers moteurs (ce n'est pas seulement une façon d'unifier les drivers sgbd de php). Enfin bon c'est assez secondaire par rapport aux autres problèmes de PMO.
[^] # Re: MultiDeskOS inside
Posté par Code34 (site web personnel) . Évalué à 1.
Pour répondre à ta question concernant le relationnal mapping effectivement PMO est pour le moment rudimentaire au niveau manipulation des maps, il y a les structures de données, mais pas les méthodes pour travailler dessus, pas d'itérateurs non plus;
De même Pmo ne gère pas le casting, comme tu l'as très justement fait remarqué PMO n'implémente pas de design pattern lazy loading (c'est d'ailleurs le sujet de ce fil). Il y a plein de choses à faire.
Enfin je pense que c'est facile de trouver des défauts à une API taguée 0.07 avec 1 développeur qui rédige les docs, le manuel, pond des articles sur les sites. C'est plus simple pour moi de faire un screencast que d'organiser des conférences power point (j imagine que tu le comprendras) ;)
[^] # Re: Mmmm, voyons voir...
Posté par Raphaël G. (site web personnel) . Évalué à 1.
Il vaudrais mieux un truc comme ça :
$pmo = pmo_record::singleton()->get_by_login('ancienLogin');
$pmo->login = 'nouveaulogin';
$pmo->commit();
J'ai mis pmo_record::singleton()->get_by_login au lieu de pmo_record::get_by_login pour avoir a éviter des problèmes entre fonctions statiques et non qui peux générer des erreurs strictes.
Après tu ajoute dans ta classe pmo_record (enfin un classe qui gère qu'une ligne) deux fonctions magiques :
public function __call($name,$param); //pas sûr du prototype, voir doc
Elle va se charger de décrypter ton get_by_xxx qui n'existe pas, que tu va mapper vers une fonction get_by qui prend un tableau de toutes les conditions a utiliser pour faire la clause where du select.
Ensuite pour le $pmo->login, tu utilises une fonction magique :
public function __set($key, $value);
Comme ça ton attribut est affecté sinon tu plante.
En bonus on peux imaginer que la fonction singleton a le prototype suivant :
public static singleton($table_name);
Et va se charger de créer un objet vide pour la table avec les bonnes données (NULL quand la table mysql est a null ou valeur par défaut).
Bon ça risque de poser des petits soucis pour implémenter un gestion de l'id automatique.
ps : ceci est fortement inspiré de l'active record de ruby, et le plus serait de le coder en module php et plus en php tout court ;)
[^] # Re: Mmmm, voyons voir...
Posté par Code34 (site web personnel) . Évalué à 0.
Ma réponse ici:
http://code34.girafon.org/reponse2.txt
[^] # Re: Mmmm, voyons voir...
Posté par Bruno Michel (site web personnel) . Évalué à 2.
$pmo->login = 'nouveaulogin';
En terme de lisibilité, c'est mal, même si derrière ça fait appel à une
méthode et que la variable est protected.
La deuxième raison c'est que les objets de PMO sont extensibles, et que
l'utilisateur peut utiliser ces propres objets grace au polymorphisme.
Implémentation des magiques pour d'autres fonctionnalités.
Comparaison:
$pmo = pmo_record::singleton()->get_by_login('ancienLogin');
$pmo->login = 'nouveaulogin';
$pmo->commit();
Le code PMO actuel
$object = $map->getObjectByValue('utilisateur","login","ancienLogin");
$object->setAttribute("login","nouveaulogin");
$object->commit();
Etant donné que cela fait quand même plusieurs fois qu'on me soumet cette
évolution, je vais tout de même y réfléchir.
Au niveau de la méthode singleton, cela est implémenté de cette manière:
$object = $controler->createObject("utilisateur");
Le controleur va créer l'objet avec les bons attributs initialisés à blanc. Il
est fort possible que dans la prochaine version la méthode create soit intégré
dans l'objet
$object->create('utilisateur");
[^] # Re: Mmmm, voyons voir...
Posté par Bruno Michel (site web personnel) . Évalué à 2.
[^] # Re: Mmmm, voyons voir...
Posté par Code34 (site web personnel) . Évalué à 1.
[^] # Re: Mmmm, voyons voir...
Posté par Code34 (site web personnel) . Évalué à 1.
J'ai implémenté le __set() et __get() dans l'objet. Je garde une réserve pour l'implémentation de ces méthodes dans la map.
J'ai également corrigé la faute controler -> controller
[^] # Re: Mmmm, voyons voir...
Posté par Raphaël G. (site web personnel) . Évalué à 2.
Mais finalement ça marche bien si tu documentes les choses correctement...
Bon en fait je suis en train de repenser une application et avoir un pmo qui agis au niveau record ça me serait assez pratique.
A savoir ton controleur est a initialiser une fois au début.
(il se charge de se mettre en global et compagnie)
Après tu ne fait plus qu'appel a :
$record = record::singleton('table');
Ton singleton va faire ça :
- public static singleton($table, $id = null)
- récupération du controleur si existant, instanciation d'un nouveau au besoin
- créer l'objet avec les attributs et valeurs par défaut de la table
- retourner l'enregistrement
Après il n'y a plus qu'a faire joujou avec.
Par contre tout ce qui est dérivation de l'objet est a mon avis pas un problème avec les magiques.
Pour la bonne et simple raison que l'objet dérivé devra simplement veiller a appeller parent->magique() avant de faire son code a lui.
Ainsi ça marche au poil.
Après il y aurait plusieurs classe a faire :
- controleur
- record
- liste de record
Et bien sur tu te débrouille pour placer les objets dans une table de hashage du controler pour qu'il renvoie l'objet précédent si on a un couple table+id identique...
[^] # Re: Mmmm, voyons voir...
Posté par Code34 (site web personnel) . Évalué à 1.
A mon avis tu te poses des problèmes, ou il n'y en a pas ;)
dans pmo
controleur = controller
record = objet
liste de record = map
Le controleur n'a pas besoin d'être singleton. Le role du controleur c'est de remplir les maps avec des objets qu'il instancie. Lui il n'est en fait qu'un objet vide avec des méthodes qui stocke des références. Bien que ça soit inutile, tu peux instancier plusieurs controleurs, ou garder dans une variable de ta propre classe une référence vers le controlleur que tu utilises. Mais c'est aussi tout à fait correct d'utiliser 2 controlleurs différents en parallèle.
La table de hashage existe également c'est un objet à part entière ;)
Pour le __set et __get j'ai implémenté les méthodes hier soir, dispo sur le subversion;
[^] # Re: Mmmm, voyons voir...
Posté par Code34 (site web personnel) . Évalué à 1.
[^] # Re: Mmmm, voyons voir...
Posté par herodiade . Évalué à 4.
Au cas où tu ne l'ai pas déjà fait, il pourrait être prudent de jetter un oeil sur les frameworks complets existants, faits par des gens qui connaissent les besoins caractéristiques (des fw qui sont utilisés en prod, par exemple), et pas par des étudiants qui croient découvrir la lanterne magique.
Peut-être quelque chose comme :
http://www.cakephp.org/
http://www.symfony-project.com/
http://seagullproject.org/
etc.
En outre le choix de licence (GPLv3) de phpmyobjet t'impose de passer ton appli sous ce régime, et de ne pas utiliser d'autres libs sous une licence incompatible (comme, au hasard, GPLv2, LGPL, openssl, ...), ce qui est un beau sacrifice pour une telle lib.
Outre les critiques adressées ici, un exemple tiré du code source :
public function getAttribute($name) {
if(isset($this->object_attribute[$name]))
return $this->object_attribute[$name];
return FALSE;
}
J'imagine que la gestion des exceptions, ou différencier les attributs inexistants des attributs vides, c'est secondaire chez PMO...
[^] # Re: Mmmm, voyons voir...
Posté par Code34 (site web personnel) . Évalué à -2.
-1 Pour le troll php et sql ;)
[^] # Re: Mmmm, voyons voir...
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2.
C'est l'utilisation systématique du SELECT * qui est gorête. On ne doit sélectionner que les champs dont on a besoin. Tout tirer de la base de données pour coller dessus du "mapping machin-chose", pour moi, c'est lourd et disgracieux. Voilà pourquoi.
[^] # Re: Mmmm, voyons voir...
Posté par Code34 (site web personnel) . Évalué à -1.
En plus, si par exemple tu as une table utilisateur, utiliser des select précis sur les colonnes signifie que derrière tu vas avoir autant de méthodes que de select pour modifier ces colonnes.
Au final, tu vas avoir une quantité de code qui va croite à chaque fois que t apporteras des modifications à tes tables. Rajouter d'une méthode par exemple pour parametrer le login, le mail , le pass etc ... Au final, ton gain de performances sera à peine quantifiable, et par contre ton code sera tellement gros qu'il te sera de plus en plus difficile de le maintenir.
PMO pourrait utiliser des select sur des colonnes mais ça n'a pas d'intérêt, étant donné qu'il te donne un objet qui représente une ligne de ta table, et tu peux à partir de cet objet filtrer ce que tu veux utiliser. Tout le select n'est donc pas renvoyé comme ça.
Je sais très bien que je n'arriverais pas à te convaincre, il y a tout de même un bench ici
http://pmo.developpez.com/versions/0.07/#LIII
[^] # Re: Mmmm, voyons voir...
Posté par Anonyme . Évalué à 8.
On ne te parle pas de traitement de requête mais de transfert sgbd->php, de deux chose l'une :
- soit tu charges systématiquement toutes les données de ta ligne, et donc sur une table avec plein de champs tu vas tout charger même ce dont tu n'as pas besoin -> overhead coûteux inutile.
- soit tu charge les attributs de ta ligne a la demande et la tu multiplie les échanges entre ta librairie cliente du SGDB et ton serveur -> overhead coûteux inutile.
Sachant qu'un outil de mapping objet se doit être très générique pour coller a un maximum de besoin, tout les types d'usages doivent être satisfaisant : pas moyen de s'en sortir en disant a ton utilisateur qu'une table a 80 colonne c'est débile (même si dans l'absolu, c'est vrai : tu n'es pas maitre de ses contraintes. Pour ma part je fait de la BD géographique, et des champs peuvent être très gros, sans que l'on veuille forcément les charger).
En plus, si par exemple tu as une table utilisateur, utiliser des select précis sur les colonnes signifie que derrière tu vas avoir autant de méthodes que de select pour modifier ces colonnes.
Au final, tu vas avoir une quantité de code qui va croite à chaque fois que t apporteras des modifications à tes tables. Rajouter d'une méthode par exemple pour parametrer le login, le mail , le pass etc ... Au final, ton gain de performances sera à peine quantifiable, et par contre ton code sera tellement gros qu'il te sera de plus en plus difficile de le maintenir.
Gni ? c'est pas géré en dynamique tout ca ? le premier truc que j'attendrais d'un mapping c'est de justement que mes méthodes soient crées automagiquement ! m'enfin je sais pas si php permet ce genre de choses :) (autrement que par un générateur de code)
PMO pourrait utiliser des select sur des colonnes mais ça n'a pas d'intérêt, étant donné qu'il te donne un objet qui représente une ligne de ta table, et tu peux à partir de cet objet filtrer ce que tu veux utiliser. Tout le select n'est donc pas renvoyé comme ça.
C'est fumeux. J'ai l'impression que tu parts du principe que ton analyse est la bonne et que tu défends le fonctionnement. Profite des exigeants lecteurs de linuxfr et donne leur en pature ton travail en expliquant comment tout cela fonctionne plutôt que d'essayer d'expliquer pourquoi c'est bien. Ton projet a l'air jeune, tu t'es fait la main sur les premières versions, c'est peut être l'heure de tout casser pour repartir sur du propre et débattu :)
[^] # Re: Mmmm, voyons voir...
Posté par Code34 (site web personnel) . Évalué à -1.
On ne te parle pas de traitement de requête mais de transfert sgbd->php,
problème d'infra
soit tu charges systématiquement toutes les données de ta ligne, et donc sur une table avec plein de champs tu vas tout charger même ce dont tu n'as pas besoin
Les problèmes que tu te poses ne sont pas liés à PMO mais à ton mcd, ou ton diagramme de collaboration/classes. Tu as mal conçu ton programme, de ce fait tes objets possèdent des attributs qu'il ne devraient pas posséder / manipuler.
soit tu charge les attributs de ta ligne a la demande et la tu multiplie les échanges entre ta librairie cliente du SGDB et ton serveur
PMO ne fonctionne pas comme ça
Sachant qu'un outil de mapping objet se doit être très générique pour coller a un maximum de besoin, tout les types d'usages doivent être satisfaisant : pas moyen de s'en sortir en disant a ton utilisateur qu'une table a 80 colonne c'est débile (même si dans l'absolu, c'est vrai : tu n'es pas maitre de ses contraintes. Pour ma part je fait de la BD géographique, et des champs peuvent être très gros, sans que l'on veuille forcément les charger).
PMO n'est pas là pour pallier à des problèmes de conception. Si tu as une table avec 80 colonnes, c'est que t'as déjà un problème flagrant de MCD. De même PMO n'exclue pas la possibilité d'utiliser des colonnes. Tout dépend de l'implémentation de la class du parser SQL
gni ? c'est pas géré en dynamique tout ca ? le premier truc que j'attendrais d'un mapping c'est de justement que mes méthodes soient crées automagiquement ! m'enfin je sais pas si php permet ce genre de choses :) (autrement que par un générateur de code)
C'est ce que j'expliquais au dessus quand on utilise par un mapper comme PMO, on multiplie les lignes de code.
C'est fumeux. J'ai l'impression que tu parts du principe que ton analyse est la bonne et que tu défends le fonctionnement. Profite des exigeants lecteurs de linuxfr et donne leur en pature ton travail en expliquant comment tout cela fonctionne plutôt que d'essayer d'expliquer pourquoi c'est bien. Ton projet a l'air jeune, tu t'es fait la main sur les premières versions, c'est peut être l'heure de tout casser pour repartir sur du propre et débattu :)
Tu me fais rire : "les exigeants lecteurs de linuxfr". Ce fil de discussion découle du fait qu'un exigeant lecteur n'a lu que partiellement les doc.
Il y a des bonnes et des mauvaises critiques sur ce site, souvent on se retrouve confronté à des réactionnaires, mais ça n'en reste pas moins un média.
De là à dire qu'il faut recommencer un projet juste pour améliorer l'implémentation de méthode dans la class parser ...
# Soyons chieur en ce lundi matin...
Posté par windu.2b . Évalué à 3.
Tel que je lis ça, j'en déduis que PMO v0.06 peut créer 29 objets par seconde (et PMO v0.07 en créerait 0,2 par seconde). Ce qui donne un léger (oui, j'aime les euphémismes) désavantage pour PMO 0.07
Je suppose que tu voulais dire qu'il faut respectivement 29 et 0,2 secondes pour créer les objets?
1 http://pmo.developpez.com/versions/0.07/#LIII
[^] # Re: Soyons chieur en ce lundi matin...
Posté par Code34 (site web personnel) . Évalué à 1.
Oui c'est bien ça, Pmo v0.07 met 0,2 sec à créer 3000 objets avec une des tables de ref sakila
Alors que la v0.06 mettait 29 secondes.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.