Reprise du message précédent :
Si ce code était utile (), tu devrais utiliser __call pour gagner en lisibilité :
l'appel d'une fonction get_quelquechose() trouverais dynamiquement qu'il faut renvoyer $this->quelquechose.
Clair que c'est chiant que çà soit pas indenté et que global c'est bof

 
c'est mal.

 
C'est mieux    
 
EDIT : c'est quoi ce bug avec les quotes : un smiley à côté d'un point ça bugge seulement dans les quotes

il ira mieux sorti de l'hosto  
 
EDIT : moi çà s'arrange pas

 
C'est quoi le pb que vous voyez avec __call  

 
+1

C'est une fonction Php

sur un objet complexe ou un truc dont la structure a bougé suite à un refactoring tu te retrouves vite avec un énorme paté pour gérer les cas particuliers, et ça devient nettement pire que d'avoir un getter et un setter par membre que tu veux atteindre...

C'est clair que si c'est juste pour des getter et setter ça vaut pas trop la peine sur des objets complexes
 
Sur des objets comme celui-là c'est très pratique : http://svn.symfony-project.com/plu [...] Finder.php (dernière méthode)

exemple  : ma classe user à une chiée d'attribut ( issus du ldap ) , je me vois bien avoir autant de getter ou de setter , juste pour le plaisir  
 
a la place, j'ai tous mes attributs sauf deux, qui sont définis en protected . Les deux autres sont des attributs non modifiables, donc défini en private avec des getter explicites , et j'ai une classe  qui se concentre sur son objectif et qui n'est pas une catalogue de getter et de setter

 
...et c'est un super exemple de ce que je disais : un gros paté moche, catalogue de if() pour traiter les différents cas.
 

 
...et ça a un intérêt d'avoir une visibilité des attributs ldap hors de ta classe user? A priori non, puisque tu les déclares protected sans getters/setters. Ou alors c'est _call qui est utilisé pour ceux-là? Si oui, euh, quel est l'intérêt de laisser visible des attributs ldap hors de la classe user? Et qu'est-ce qui se passe si un jour ta source de données ou la structure de ton ldap changent?
Des getters/setters ce n'est pas forcément un mappage direct vers la lecture ou l'affectation d'une variable...pour moi il y a toujours un intérêt à les déclarer explicitement lorsque tu en as besoin...

Tu m'expliques comment tu apportes la meme souplesse au niveau de l'API pour l'utilisateur de la classe sans ça ?
Ca factorise vachement le code.

aucune idée, j'ai pas regardé ce que ça faisait...j'ai juste vu exactement ce que je pensais trouver : une grosse fonction de je sais pas combien de lignes qui consiste uniquement en une suite de if() pour traiter les cas différents, au lieu de les traiter dans des fonctions séparées.

Et quoi qu'il arrive il y a toujours plusieurs solutions à un problème, et celle-ci n'est certainement ni la plus élégante ni la plus simple à comprendre et à maintenir.

__call est utilisé pour mapper automatique les getter et les setter sur les attributs qui sont quasiment tous accessibles de l'exterieur. ceux qui ne doivent pas l'etre sont défini en private

si jamais la structure de mon ldap change ( ce qui est assez rare quand meme) il me suffira de définir explicitement les getter/setter qui ont besoin de l'être, et de ne pas toucher les autres.
Exemple  : je fais de la lazy instanciation pour certaiens donénes de l'utilisateurs qui sont lourdes a chargée et peu utilisée. Dans ce cas ; le getter est défini exlpicitement

Pour tous les getter / setter  qui ne sont pas du mapping direct, c'est clair qu'il faut les définir explicitement. Mais pour les autres, pourquoi alourdir le code avec des lignes qui n'apportent rien ?

J'utilise ce code :

<?
    class EntityException extends Exception {};
     
    /*
    *   Provides automatic accessors like getMyparam() or setNicevalue('foo');
    */
    abstract class Entity
    {
     protected function set($prop, $val)
     {
       $this->$prop = $val;
       return true;
     }  
     protected function get($prop)
     {
       return $this->$prop;
     }  
     protected function est($prop)
     {
       return $this->$prop ==true;
     }  
     
     public function __call($method, $params)
     {
       $type = substr($method, 0, 3);
       $prop = strtolower(substr($method, 3));
       $paramCount = count($params);    
       if (property_exists($this, $prop)) {
         switch ($type) {
         case 'set':
           $nb = 'exactly 1';
           if ($paramCount === 1) return $this->set($prop, $params[0]);
           break;
         case 'get':
           $nb = 'no';
           if ($paramCount === 0) return $this->get($prop);
           break;
          case 'est':
           $nb = 'no';
           if ($paramCount === 0) return $this->est($prop);
         default:  
           throw new EntityException("Unknown method: $method" );
         }
         throw new EntityException("Invalid args count $method() takes $nb argument." );
       } else {
         throw new EntityException("Unknown property: $prop, $type() failed." );
       }    
     }
    }
    
    ?>

et toutes mes classes hérites de Entity

Ne serait-ce que pour la lisibilité du code. Pouvoir appeler des méthodes qui n'existent pas est un concept qui fondamentalement me dérange beaucoup.
Et en ce qui me concerne je considère qu'on doit pouvoir savoir comment utiliser une classes en regardant la liste de ses membres et fonctions publics, ce qui n'est plus du tout le cas dès qu'on joue avec ces horreurs spécifiques à php.

Avoir des getters/setters explicites pour certains membres et pas pour d'autres c'est le bordel. Et ta méthode __call si tu ne vérifies pas derrière quels membres sont demandés tu te retrouves avec des membres privés accessibles et modifiables que tu le veuilles ou non, ce qui est amha la pire hérésie qu'on puisse commettre.

[...]

 
bravo, ça revient à déclarer tous les membres de toutes tes classes pour lesquels tu ne redéfinis pas les getters/setters publics.

donc tu redefinis aussi toutes les méthodes héritées ? parceque si tu ne le fait pas , tu ne peux pas utiliser une classe sans lire le code des classes parentes

non

un membre déclaré  en private n'est pas accessible avec ce mode de fonctionnement
je t'aide, avec la  doc sur property_exist http://us2.php.net/property_exists

sans lire quelles sont leurs propriétés et fonctions publiques.
Avec _call il faut lire le code...

Tu appelles property_exists dans ton __call,  les deux sont dans la même classe, donc je vois pas pourquoi ça retournerait false...remarque avec un héritage je suis jamais sûr de ce que fait php, m'enfin je vois pas de raison logique pour laquelle le property_exists retournerait faux.

rien ne t'empehce de documenter les fonctions qui sont 'virtuelles'
on aprle juste de gagner du temps a l'ecriture eu au debuggage

tu devrai tester alors, tu serai surpris ( ici sous php 5.2.1 ca fonctionne )

 
tu en perds ailleurs, là...
 

 
Effectivement ça marche...mais mauvais esprit comme je suis j'en déduis plus facilement que property_exists est buggé qu'autre chose.
...et en passant outre ce truc, tu t'interdis tout nom de variable membre contenant une majuscule, c'est quand même particulièrement casse-burnes...
 

class totoz extends Entity{
           
                  
           private $titi;
           public $toto;
           public $laCaBuggeGrave;
           
           function __construct(){
               $this->titi = 0;
               $this->toto = 0;
               $this->laCaBuggeGrave = 'dawa';
           }
    
           
           
       }
       
       $dawa = new totoz();
       $dawa->setToto('ok, lol');
       $dawa->setLaCaBuggeGrave('moule_bite');
       print_r($dawa);

d'ailleurs vu que ça marche avec les membres publics je vois pas pourquoi ça marcherait pas avec les membres privés, c'est particulièrement incohérent ce bordel...tu réécris un __call équivalent sur toutes les classes dérivées qui ont beaucoup de membres privés qui ont besoin de setter/getter?

tu vire le strtolower si ca te pose vraiment un problème éthique
mais de toute manière, le nombre de situation ou tu dois taper directement le nom de la variable est super rare chez moi, c'est pour ça que je défini des getter et des setter  
 
 

tu as surement mal compris les raisons qui font qu'un membre est privé.
C'est privé comme dans privatif, propre à la classe, et donc ça n'a rien a foutre à l'extérieur , sinon, c'est protected ou public . Et tu remarquera que, dans ce cas, on retombe dan sune situation bien chiante, qui est exactement celle que tu conseille.
 
si je défini un getToto() le call ne va pas etre appelé

les seuls getter/setter que je définis explicitement sont les membres calculés et les  membres sur lesquels je fais du lazy loading ( rare car je ne le met en place que si c'est un goulet d'etranglement )
 
 
 
exemple de classe ou j'utilsie ce principe :  
 

class Profil extends Entity{
 
    protected $nom;
    private $id;
    protected $administrateurs = array();// id des profils qui ont le droit de modifier les membres de ce profil
    protected $idusers  = null; 
    protected $ldapusers = null;
 
    function __construct($idProfil)
    {
        $idProfil = mysql_real_escape_string($idProfil);
        
        $this->id = $idProfil;
        
        $query = "SELECT nom
                    FROM noyau_groupes
                    WHERE id = $idProfil";
                    
        $result = mysql_query($query);
        
        if(mysql_error())
            return;
            
        if(mysql_num_rows($result) ==0)
            return ;
        
        list($this->nom) = mysql_fetch_array($result);
        
        // on recuperer la liste des profils administrateur de ce profil 
        $query = "SELECT idGroupeAdmin 
                    FROM noyau_groupes_admin 
                    WHERE idGroupe = $idProfil";
        $result = mysql_query($query);
        if(mysql_error())
            return;
        
        while(list($id) = mysql_fetch_array($result))
        {
            $this->administrateurs[] = $id;
        }
        $this->administrateurs[] =1; // on rajoute le profil super admin 
        
    }
    
    function getId(){
        return $this->id;
    }
    
 
    function getIdUsers(){
        if($this->idusers ==null && $this->getId() >0 )
        {
            //liste des utilisateurs membres de ce profil ( stocké en base , ne contient que les personnes qui se sont connecté au moins une fois) 
            echo '.';
            $query = "SELECT id_user 
                        FROM noyau_groupes_users INNER JOIN noyau_users ON noyau_users.id = noyau_groupes_users.id_user
                        WHERE id_groupe =".$this->getId()." AND actif=1 AND supprime =0";
            $result = mysql_query($query);
            if(mysql_error())
                return;
 
            while(list($idUser) = mysql_fetch_array($result))
            {
                $this->idusers[] = $idUser;
            }
        }
        return $this->idusers;
        
    }
    
    function getLdapUsers(){
    //recup de la liste des données du ldap  des membres de ce profils ( tout le monde , y compris ceux qui ne se sont jamais connecté ) 
        $ldap = new ldap();
        $this->ldapusers = $ldap->recherche_profil($idProfil);
        
        
    }
}

 
id est défini en privé, pas modifiable, je fait donc un getter explicite  
la liste des utilisateurs est assez couteux a récupérer, je défini donc un getter explicitement

 
oui, mais là t'es obligé d'avoir des noms de variables qui commencent par une majuscule, bref, il faut que ça matche, ce qui est pénible et sort des conventions de nommage les plus utilisées...
 

 
ok, lol, tu vas m'apprendre ce que ça veut dire ou à quoi sert private maintenant.
Un membre peut être privé dans le seul objectif de cacher l'implémentation interne de la classe, et on peut très bien avoir besoin d'utiliser sa valeur telle quelle hors de cette classe quand même. Je n'utilise absolument jamais de variables membres publiques, ne serait-ce que pour éviter d'être emmerdé en cas de refactoring ultérieur.
 

 
c'est bien ce que je dis, si tu as besoin ne serait-ce que d'un getter sur un membre private tu n'as pas le choix il faut l'écrire...

('tain et property_exists trouve aussi les protected dans les classes filles...c'est n'importe-quoi ce truc )

a oui , c'est horrible    
allez, vu que je suis un gars gentil, je t'aide  

et , est ce que j'ai dis que ca faisait tout ton code a la place ?  
non, j'ai dis, qu'en ajoutant extends Entity aux classes de base, tu évite de te taper une bonne partie  des getter/setter , ce qui allège les classes. Je vois même pas pourquoi tu te focalise sur tes private. A moins que tu déclare tout en priavte, parceque c'est mieux .
C'est sur qu'il vaut mieux avoir 200 lignes de getter/setter au début, c'est tellement mieux pour lire le code

Je pense que vous êtes nombreux à ne pas avoir compris mon idée.
 
Je parle d'un générateur de classes du type table de la base de donnée qui donne table.php, qui prends en considération les null autorisés, les relations foreign keys, les collections d'objets enfants, l'accès à l'objet parent. Je ne cherche pas à avoir le code le plus sexy mais à ne plus faire de SQL pour sauvegarder mes objets plus complexes qui héritent de mes classes de base.
 
L'objectif étant de générer la couche d'accès aux données de cette façon à chaque modification ou nouveau projet, gagner du temps en gros.

Question n0ob :
J'ai un système simple (News) et je dispose de fichiers du type index.php (listage) comments.php (commentaires) post.php (création de news) tocomment.php (envoi de commentaires)....
 
Est-ce intéressant, pour le contrôleur, d'utiliser le nom du fichier en cours pour gérer les requêtes ?
 
J'utiliserais basename et switch, par exemple.

c'est plutot l'inverse qui se passe en général : l'internaute accède à aux différentes url, qui mènent en fait toutes au même fichier (avec le type de page en GET, via url-rewriting, notament). Dans ce fichier là (front-controller), tu peux faire ton switch (et regardant direct le GET)

Ouais, je pense que c'est mieux
J'avais fait çà (assez crade ) :
http://lucasavoie.com/files/news.zip

Effectivement je ne connaissais pas, j'aurais le plaisir d'utiliser le mien toujours plus gratifiant )

J'étudierais ca après mon projet, il est déjà bati autour de mes classes générées.

erf
j'ai trouvé un bug dans la gestion de l'encodage dans le formulaire de symfony (la version 1.1.1)  

C'est-à-dire ?
T'as fait un ticket j'espère

j'attends que sur le forum de sf on me confirme que c'est bien un bug et pas une feature