• [^] # Re: Mmmm, voyons voir...

    Posté par . En réponse au journal PMO v 0.07 déjà. Évalué à 2.

    Voyons voir l'exemple de code qui donne une idée de l'API :


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