Code34 a écrit 1035 commentaires

Merci Bruno ;) Je ne sais pas pourquoi cela ne marchait pas. Je suis entrain de commiter le cvs avec les modifications évoqués ci-dessous.

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

pareil qu'au dessus, je n'arrive pas à répondre à ton post :/ Le code de pmo ne doit pas être apprécié par le parser de linuxfr :/

Ma réponse ici:
http://code34.girafon.org/reponse2.txt

Impossible de répondre à ton post. Je ne sais pas pourquoi, le site refuse mon commentaire.

la réponse dans un fichier texte ici:
http://code34.girafon.org/reponse.txt

Depuis quand un select * est goret ?

-1 Pour le troll php et sql ;)

Pour ceux qui souhaitent de près ou de loin participer au projet ou soumettre des idées d'évolutions, un newsgroup a été crée ici:

http://groups.google.fr/group/pmo-dev?hl=fr

Salut Ummon,

Très juste. Les modifications dont tu parles notament au niveau de l'interface pour la map font parti justement des améliorations principales de la 0.06 qui va sortir :D

La map devient une interface avec une classe concrète qui l'implémente.

salut,

La version 0.06 va être la première à proposer véritablement le support des relations.

Très bonne remarque, ça sera fait pour la 0.06.

Il y aura également (pour la première fois) la phpdoc.

C'est sur c'est loin d'être l'idéal. Comme je suis seul sur ce projet, et que je travaille, et que je m'occupe d'autres trucs à coté, j'ai pas tout le temps que je souhaiterais pour faire les choses dans les règles de l'art ;)

Si tu souhaites participer à la réalisation des docs, du site, et des vidéos, tu es le bienvenue.

Partiellement pour la 0.04. L'aspect relationnel dans la 0.05 devrait être mieux conçu.

Le mieux c'est que tu l'essaies, tu comprendras ce que fait pmo par rapport aux autres projets.

J'insiste vraiment sur ce fait: phpmyobject ne mappe par les résultats dans un objet

phpmyobject mappe 1 ligne de résultat dans autant d'objets qu'il y a des tables concernées

Je pense (et je peux me tromper car je n'en ai pas personnellement l'utilité) que c'est une mauvaise idée de développer un outil qui proposerait une abstraction à SQL si celle-ci n'apporte pas des fonctionnalités plus puissantes.

Bien entendu libre à chacun de proposer des évolutions.

Je suis preneur, envoie moi le code(car je ne connais pas l'implémentation postgress), et je ferais évoluer la class sgbd

peut être mas pas sur ...

Je ne citais pas ça en tant qu'avantage, je décrivais vulgairement l'implémentation du fetch object de php5. S'il y a un module comme pdo qui permet de manipuler les résultats des requêtes sql plus précisement en oo c'est très bien.

Ca n'a pas de rapport. Pdo permet de manipuler les résultats du sgbd, tout comme le fait pear.

Tu peux implémenter l'interface controleur, et sqlparser de phpmyobject en utilisant pear ou pdo, ça n'a pas d'importance, mais ça n'intervient pas au même niveau.

pdo et pear sont des objets qui manipulent des sgbd.
phmyobjet crée des objets dynamiquement calqué sur le modèle relationnel de ta base.

Je pense qu'il y a une incompréhension par rapport à ce que fait Phpmyobject.

Phpmyobject n'est pas un générateur de requêtes sql comme l'exemple que tu donnes ci-dessus.

Il n'est pas non plus un ensemble d'objets qui permettent de manipuler un sgbd comme pear.

Phpmyobject est un générateur d'objet. Il ne crée pas des objets dans les bases du sgbd, il crée des objets dynamiquement du coté du serveur d'application à partir des résultats d'une requête sql.

La différence fondamentale entre le fetch object de php tel qu'il est implémenté et phpmyobject sont:

- le fetch object de php renvoit 1 seul et unique object par tuple. Cette objet à ma connaissance n'embarque aucune méthode, et récupère en propriété tout les champs du tuple

- phpmyobject retourne autant d'objets qu'il y a de tables par tuple. Ces objets récupèrent dynamiquement les propriétés des attributs de la table, et embarque avec eux des méthodes qui permettent de récupérer et modifier ces objets, d'ailleurs ces objets peuvent être très bien étendu.

Ca ne fait pas la même chose que Pear.

Plus de détails par rapport aux autres projets dans mon post précédent
http://linuxfr.org/~Code34/24247.html

bah si tu utilises un langage de script, autant tirer parti de l'interpréteur et ne pas développer comme si c'était du compilé.

Avoir des méthodes setTitle cela sous entend que tu vas avoir des classes différentes pour chaque type d'objets embarquant leurs propres méthodes pour manipuler les attributs.

Ici, t'as une seule classe mère tuple qui possède donc les deux méthodes, + simple + élégant après tu peux bien entendu créer des classes filles avec des méthodes setTitle, mais ça n'a aucun intérêt car la class mère à la capacité de le faire.

L'utilité de manipuler des objets distincts est de pouvoir ensuite modifier , et enregistrer les objets ensuite dans la base.

Avec la méthode générique , extraire une ligne et la considérer comme un seul objet, c'est dans l'optique de l'afficher.

De même si tu modifies la valeur d'un de tes attributs, tu seras contraint d'opérer directement la modification sur la base via un update et c'est mal !

>> un objet ne se résume pas à une table = un objet, mais il est normalement possible de faire plusieurs tables = un objet.

Oui c'est possible c'est le comportement par défaut de la fonction php5 mysql_fetch_object

http://fr.php.net/manual/fr/function.mysql-fetch-object.php

qui te renvoit chaque tuple sous la forme d'un seul et unique objet...

Ca n'a donc pas d'intérêt de développer une api qui fasse cela.

En fait, dans l'exemple ci dessus tu n'as qu'une table.

Le postulat de base concernant l'utilisation de cette api est de considérer chaque enregistrement contenu dans une seul table comme un objet.

Si tu fais un select sur deux tables jointes, tu récupères une seule ligne de résultat.

Hors si le résultat provient de deux tables à la fois, le seul objet que tu vas créer ne peut être considéré comme un objet enregistrement.

L'api pour chaque ligne de résultat va donc créer autant d'objets distincts qu'il y a de tables.

Je prend un exemple

select * from db_user, db_town limit where db_user.id_town=db_town.id_town 1;

avec
db_user
=======
id _user = 1
user_nom = toto
id_town = 1

et
db_town
=======
id_town = 1
town_nom = toulouse

le résultat de la requête sql va être:
id_user user_nom user_ville id_town town_nom
1 toto 1 toulouse

l'api va donc crée 2 objets distincts et non un seul.

Un objet db_user qui a comme attribue les noms de la champs de la table db_user, et un objet db_town qui a les attributes de la table db_town

ouai par rapport au code fournis en exemple sur la première page:

$book = BookPeer::retrieveByPK(5);
$book->setTitle('The Propel Story');
$book->save();

ça y ressemble. Sauf que ça me semble plus lourd à gérer. En fait, mon api gère elle même dynamiquement le nom des attributs.

exemple t as une table

book
====
titre
auteur

le code équivalent à ce qui est écrit au dessus serait:
$book ->setAttribute('titre', 'The Propel Story');
$book->setAttribute('auteur', 'toto');
$book->save(); (non implémenté)

L'intérêt est donc la dynamique étant donné qu'il n'y a pas de getter/setter à écrire.

Mais bon le truc le plus important c'est pas la manipulation des attributs, c'est la gestion des jointures de pouvoir créer plusieurs objets qui correspondent aux différentes tables à partir d'une seule ligne résultat.

La problèmatique est que SQL ne renvoit pas la provenance des résultats en fonction des tables.

je ne connais pas les subtilités de ROR en terme de manipulation d'objets, mais c'est bien orienté modèle vue contrôleur.

Mon projet était en premier lieu de concevoir une interface, et ensuite de l'implémenter .

Je ne pense pas que je refasse de mise à jour, ou que je maintienne cette API.

La seule chose que je vais apporter à court terme c'est:
- une contrainte sur l'unicité des primary keys pour qu'un objet soit unique,
- que chaque objet soit classé dans une map en fonction de son type (et non plus dans une seule map)
- implémenter la méthode pour updater les tables sql.
- peut être et la c'est du domaine du rêve, implémenter un système relationnel objet

Pour l'archive, je ne sais pas d'ou ça vient. J'ai rencontré le même problème, je l'ai réuploadé et ça a l air de fonctionner.

l api n'est pas complète, mais bon ça fait clairement pas ce qui t intérresses. C'est pas comme une class qui implémenterait jdbc:odbc. C'est pas non plus comme pear.

l'exemple d'utilisation est dans la test class. Une fois que t as renseigné les paramêtres mysql, Tu peux récupérer n''importe quel enregistrement d'une de tes tables et le manipuler comme un objet.

Par exemple
tu passes un "select * from db_user, db_ville limit 1" à ton controleur.

Il va te créer deux objets disctints(c'est ça l'essentiel) user et ville que tu peux manipuler avec les getter et setter.

Pareil si tu fais une jointure avec plus de 2 tables.

genre:
$object->getAttribute('user_login') va te sortir le nom de ton user.

etc ...

Un différent sur le paiement. Personne n'a reçu de chêque, ni l'hébergeur au datacenter, ni Girafon. Peut être un problème de poste mais ça fait depuis 15 jours que ça dure, et il faut bien payer le mois en cours, et les mois à venir au niveau du datacenter.

D'autres personnes tout aussi motivées se sont présentées, et mais non pas eu le temps d'étudier l'enchère.

Le prix de 1000 euro est effectivement symbolique . Le but étant de vendre Girafon a des personnes qui reconnaissent le travail qui a été fait, et de dissuader les personnes peu scrupuleuses ou peu motivées.

Des hébergeurs discount l'année dernière ont fait des propositions de ce type: "Nous vous faisons l'honneur de récupérer votre clientèle, et d'assurer la continuité du service et ce à titre gratuit".

Pour mémo, il s'agit d'une plateforme d'hébergement avec des clients en PROD.

Il faut donc avoir de fortes compétences en administration linux, accessoirement en développement shell, web pour faire évoluer l'ensemble.