je sais pas trop comment expliquer mon problème donc voici mon code ci dessous.
Pour info je travaille sous Windows XP avec PHP5.2.x et Zend for Eclipse  
et une partie du Zend Framework
 
 
 

 
mon probleme est que dans l'IDE, j'ai pas l'auto complétion sur $myDB
alors qu'il est une instance de Zend_DB qui contient des tas de méthodes publiques.
 
est ce une histoire de résolution de référence d'objet ou un truc comme ca ?
car on dirait que Eclipse arrive pas a faire le lien entre $myDB et l'objet retourné par Zend_DB::factory()
 
comment je peux régler ca ?

D'abord on met pas "&" en PHP5 puisque tout est passé par référence.
 
Ensuite, bah c'est normal que l'autocomplétion marche pas, t'as mis aucun commentaire :

en effet
mais meme en mettant ce commentaire ca marche pas

Chez moi ça fonctionne très bien en rajoutant les commentaires.
 
Dans ton cas ça ne fonctionne pas parce que la méthode setConnection() (bizarre un setter qui retourne un objet...) n'a pas de commentaires non plus.  
Comme la classe Database n'a pas de méthodes/attributs publique, alors c'est normal qu'il ne propose toujours rien.

La classe Database, je l'appelerais plutot "ZendDBWrapper", et la méthode setConnection renommée en "create" par exemple.

oui c'est effectivement un wrapper
le setConnection() en fait c'est pour instancier Zend_DB a l'intérieur de Database.
effectivement son nom est pas normalisé.
J'aimerais surcharger cette classe en la faisant hériter de Zend_DB
mais comme Zend_DB::factory() renvoit un objet en fonction de l'adatptateur, la classe Database ne peut pas hériter d'une classe qu'elle ne connait pas d'avance.
Du coup je wrappe les méthodes générales...
 
Tu verrrais une autre manière ?

en fait, en regardant, je me dis ici pourquoi wrapper ?
 
Parce que l'interet de wrapper c'est de masquer le fonctionnement de la couche sous-jacente, alors qu'ici tu wrappes mais tu renvoies la couche sous-jacente... Donc la classe Database ne sert à rien.
 
J'appelerai plutot ta classe "Zend_DB_Singleton" en fait, et elle se charge d'appeler la méthode "factory" de la classe Zend_DB pour instancier la connexion à la base de données la première fois qu'elle est demandée.
 
On a donc la classe Zend_DB_Singleton avec deux méthodes :
- getUniqueInstance() : renvoie un singleton
- getNewInstance() : renvoie une nouvelle instance ; cette méthode sera private, ou sinon public si une nouvelle connexion à la bdd s'avère nécessaire.
 
La méthode getUniqueInstance() fera un appel à la méthode getNewInstance() pour créer l'instance qu'elle va garder dans un champ static de la classe, comme tu l'as déjà fait.

oui sur le fait que c'est une classe singleton
par contre l'intéret est aussi d'en faire un wrapper, pour justement masquer la couche sous jacente.
L'idée est d'utiliser une classe DB a nous, qui derrière utilise Zend tout comme elle pourrait utiliser n'importe quel composant de DAL histoire d'avoir une application qui dépend le moins possible du framework (si un jour on devait en changer)
 
Comment verrais tu une telle classe en tant que "vrai wrapper"
Pour moi un wrapper de base surcharge les méthods du composant qu'il wrappe.
 
Je ne l'a pas mis dans le code ci dessus car ce n'etait pas dans le propos de départ
mais ma classe Database implémente les méthodes select, update() etc ...qu'implémente Zend_DB.
En gros : Database->select() utilise Zend_DB->select(), donc de facon encapsulée
 
Je trouve que j'implémente assez bien la notion de wrapper de cette manière

S'il est prévu dans le cdc de pouvoir changer de système d'accès à la bdd ça a un interet, sinon aucun à part réduire les perfs.

le cdc dit que "si c'est possible faites le"

Pourquoi pas, il faudra que le wrapper soit suffisamment générique et bien étudié pour pouvoir ensuite s'adapter à n'importe quel ORM.  
 
Je doute honnêtement que ça soit possible de faire ça proprement. Il y a un moment où il faut faire un choix technique, parce que wrapper Propel ou PhPDoctrine par exemple, bonne chance :s

Pour les besoin qu'on a, ca passe.
 
l'idée est d'implémenter peu de méthodes publiques
dans le wrapper de sorte a revoir (si ya lieu de changer un jour de DAL) uniquement le code des méthodes privées/protégées.
bref que la tambouille interne.
 
Ceci de sorte a éviter de revoir tous les appels qui sont fait au wrapper, dans toute l'appli et gagner du temps en maintenance et réécriture.
 
c'est vraiment ca l'objectif principal.

C'est dommage si c'est faire juste pour le faire, sans réel utilité prévue, "juste pour se dire qu'on est pas dépendant de la sous-couche".
 
On perd tous les avantages et les facilités que peuvent proposer ces implémentations spécifiques des accès base de données : avec phpDoctrine par exemple, le mapping des relations 1-n ou n-m facilite l'écriture des requêtes.
 
D'autant que Zend_DB semble supporter tous les types de base de données (MySQL, PostGre, Oracle...), donc la seule raison que vous auriez à pouvoir changer c'est pour des questions de performances.
 
Et les perfs, on peut bencher avant de faire son projet.

c seuelement pour pas etre dépendant du framework.
je pense que sil un jour on chaneg de framework c'est si jamais ca change de licence, genre payante, et qu'on veut pas investir pour x raisons.
 
 
J'ai vu que l'outil Magento a fait un wrapper pour Zend_DB.
Il ont du faire des bench...