Etendre l'objet record

Ca peut peut-être faire avancer le shmil-blick, j'ai fait une classe proxy pour les records, astucieusement nommée RecordProxy?, que j'attache. Mes objets métiers en héritent presque tous. J'ai également dans ce fichier une classe MapDao? qui gère les relations entre tables, en utilisant une table pivot (n pour n) ou un accès direct (n pour 1). C'est moyennement commenté et terriblement ad hoc

(comprendre noms touts pourris et pas homogènes, certains bouts et usages non testés) mais ça me semble une bonne base de réflexion.

RecordProxy? and MapDao? classes.

Milestone Not planed yet or later deleted

J'ai implémenté quelques ajouts dans jDao pour permettre d'étendre l'objet record et donc éviter d'avoir d'un coté la classe métier et de l'autre le dao, la classe métier ayant alors à manipuler le dao pour arriver à ses fins.

La modif consiste en un petit ajout dans jDaoGenerator et à 2 nouvelles classes (pour pas perturber les 2 existantes). Ces 2 classes sont :

• jDaoRecordBaseExtended.class.php (qui hérite de jDaoRecordBase)
• jDaoExtended.class.php (qui hérite de jDao)
  

(Oui les noms des classes sont pas très inspirés...)

Pour s'en servir, c'est très simple :
Lors de l'appel à jDao pour récupérer une factory, on utilise jDaoExtended à la place de jDao.
jDaoExtended recoit un paramètre supplémentaire qui est le nom de la classe souhaité pour les objets records.
Donc par exemple :
$maFactory = jDao::get('table1');
devient :
$maFactory = jDaoExtended::get('table1', 'table1Record');

Cette classe est à placer dans le répertoire classe du même module que le dao. Le fichier doit avoir un nom bien précis : dddRecordXXX.class.php où

• ddd correspond au nom du dao
• XXX est ce que vous voulez (utile uniquement si je veut avoir plusieurs classes métiers pour le même dao)
  

Par exemple si votre dao s'appelle table1 vous pouvez nommer votre classe record étendu table1Record.class.php
Le nom de la classe suit le même schéma : (dddRecordXXX)

Cette classe doit hériter de la classe jDaoRecordBaseExtended. Elle possède alors toutes les propriétés membres de l'objet record habituel (c'est implémenté via un tableau privé et des accesseurs).

L'utilisation de la factory et des records sont strictement identiques aux factories et records classique sauf qu'au niveau des records vous avez la possibilité d'y ajouter des méthodes métiers à vous :-).
Si vous y ajoutez des propriétés, il va de soit qu'elle ne seront pas prises en compte lors de l'appel à la méthode update de la factory.

Il n'est pas nécessaire de se préoccuper du chargement de la classe de votre record, jDaoExtended en fait l'include si nécessaire.

Laurent, on avait parlé de cette approche et tu me répondais que c'était contourner le pattern dao pour en faire autre chose et qu'il valais mieux réfléchir à un vrai ORM.
Je vais quand même proposer un pacth car je garde espoir de le voir intégrer. Ce patch apporte à mon sens bcp et n'est pas impactant sur jDao, c'est simplement qqch en plus qui permet de travailler de façon plus simple en attendant jOrm qui viendra un jour.

Possibilité d'étendre les objets records