Bug avec le class_loader

Bonjour,
l'utilisation d'une méthode définie via le class_loader ne fonctionne pas. La classe est introuvable.

J'ai fait une bidouille pour corriger:
Dans PMO_MyObject la methode internalfactory appelle getClassname().

Code:

---

1 2 3 4 5 6 7 8 9 10

public static function internalfactory(PMO_Table $table){ $classname = $table->getClassname(); if ($classname){ require_once(dirname(__FILE__).'/../class_loader/class_'.$classname.'.php'); $object = new $classname($table); }else{ $object = new PMO_MyObject($table); } return $object; }

---

Mais dans la classe PMO_MyTable la methode utilise un attribut qui n'est pas défini.

Code:

---

1 2 3 4 5

public function getClassname(){ if(isset($this->table_classname)) return $this->table_classname; return FALSE; }

---

En utilisant getTablename() à la place, c'est OK! :lol:

A noter que la doc indique toujours d'utiliser "extends MyObject" au lieu de "PMO_MyObject" :aie:

Et oui :mouarf: ça fait parti des modifications de la version 0.12 !

Citation:

---

L'attribut $this->table_classname est NULL

---

par défaut :)

pourquoi ?

la v 0.12 crée à la première execution une class PMO_core/cache/PMO_MyTable_lenomdetable.php héritant de PMO_MyTable (si tu veux savoir comment c'est la méthode PMO_MyTable->tocache()).

C'est cette classe qui est ensuite instanciée à la place de PMO_MyTable :)


Si tu l'édites, tu verras que l'attribut

Citation:

---

protected table_classname = NULL

---

il suffit de le setter avec le nom de ta class et cela devrait fonctionner ;)

L'avantage est que cette classe décrit la structure de ta table et définit en dur le nom de la classe PMO_MyObject que tu souhaites utiliser. Ca évite les problèmes de nom de classes déjà utilisés.

En effet, la documentation n'est pas aussi à jour que le soft :/ je fais mon max pourtant

Je viens de mettre à jour la doc pour PMO_MyObject :)

OK
j'ai testé. Cela fonctionne impec.
Cette manière de faire permet d'avoir un nom de classe différent du nom de la table.

Mais ce n'est quand même pas très naturel. C'est étonnant de devoir modifier un fichier de cache. Par définition un cache est généré pour permettre une accélération ultérieurement. Un cache a vocation à être effacé.
Ici cela ressemble plus à un fichier de configuration généré automatiquement. Le fichier est modifié pour coller au mieux à son besoin.
Une fois modifié sur sa plateforme de développement, le fichier doit être copié sur celle de production et non généré en prod.

Perso, c'est pas un problème. Je n'ai pas trop de tables. Mais j'imagine mal avec plusieurs dev en parallèle, plusieurs bases..

Merci pour ta réactivité.

Citation:

---

Envoyé par chavich

OK
j'ai testé. Cela fonctionne impec.
Cette manière de faire permet d'avoir un nom de classe différent du nom de la table.

Mais ce n'est quand même pas très naturel. C'est étonnant de devoir modifier un fichier de cache. Par définition un cache est généré pour permettre une accélération ultérieurement. Un cache a vocation à être effacé.
Ici cela ressemble plus à un fichier de configuration généré automatiquement. Le fichier est modifié pour coller au mieux à son besoin.
Une fois modifié sur sa plateforme de développement, le fichier doit être copié sur celle de production et non généré en prod.

Perso, c'est pas un problème. Je n'ai pas trop de tables. Mais j'imagine mal avec plusieurs dev en parallèle, plusieurs bases..

Merci pour ta réactivité.

---

Oui c'est exact, je n'avais pas vu la chose sous cet angle. Il s'agit en fait d'une mauvaise appellation de ma part du répertoire "cache/".

Car ce sont bien des classes, et des classes qui peuvent passer d'un environnement de dev à prod sans avoir à être regénéré ;)