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

    Posté par (site web personnel) . En réponse au journal PMO v 0.07 déjà. Évalué à 1.

    Sauf que tu généralise le cas pour un objet user...

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