378 Chapitre 9. Introduction au Zend Framework On peut gérer le layout au niveau de chaque action, soit pour modifier le docu- ment utilisé avec l’instruction // Utiliser autre.phtml comme layout $this−>_helper −>layout()−>setLayout( ’autre ’); soit en n’utilisant plus du tout le layout, par exemple pour produire un document non écrit en HTML. // Ne pas utiliser le layout $this−>_helper−>layout()−>disableLayout (); 9.4.3 Créer des Helpers La notion de Helper (assistant en français) correspond à une manière détournée d’enrichir une classe orientée-objet sans recourir à l’héritage. Nous allons prendre le cas d’un helper pour la vue. Le point de départ est le suivant : si on veut enrichir la vue avec des méthodes utiles pour tout le site, comme la mise en forme d’une date, ou d’un montant monétaire, la solution naturelle est de créer une sous-classe MaVue de Zend_View et d’y placer ces méthodes. Pour éviter cette démarche un peu lourde, le Zend Framework permet d’implanter les méthodes ajoutées sous forme de helper dont le nom et la syntaxe particulière mènent à les traiter comme des méthodes de la Zend_View. Voici un exemple simple. On veut pouvoir disposer, dans chaque vue, de l’URL de base du site. Cette URL est vide si le site est directement dans la racine htdocs du site web, sinon elle doit contenir le chemin d’accès entre htdocs et la racine du site. Pour constituer correctement les URL placées dans une vue, il faut les préfixer par l’URL de base. Il serait dangereux de la placer « en dur » dans les vues, sous peine d’avoir à changer beaucoup de choses si l’organisation du serveur évolue. On doit donc disposer de cette URL de base dans les scripts de vue. Pour cela, on place dans le répertoire views/helpers le code suivant : Exemple 9.7 zscope/application/views/helpers/BaseURL.php : la méthode ajoutée à la vue pour obtenir l’URL de base du site. <?php /∗∗ ∗ ∗ Exemple d ’un ’ helper ’ pour la vue , donnant la ∗ base de l ’application. ∗ ∗ / class Zend_View_Helper_BaseUrl { /∗∗ ∗ On prend simplement l ’URL de base dans la configuration ∗ ∗ / 9.5 Le composant Modèle du Zend Framework 379 function baseUrl() { $registry = Zend_Registry :: getInstance () ; $config = $registry−>get( ’config ’) ;; return $config−>app−>base_url ; } } Il s’agit s’une classe dont le nom est préfixé par Zend_View_Helper. La partie variable du nom de la classe indique le nom de la méthode étendant la Zend_View, soit, ici, baseUrl(). On peut utiliser cette méthode comme si elle appartenait à la vue. Voici par exemple comment on insère dans le layout le logo du site en préfixant par l’URL de base le chemin d’accès au répertoire images : <img src=" <?php echo $this−>BaseUrl() ;? >/ images/ logo .png" border="0" alt="Webscope" title="Accueil" /> La vue Zend est déjà pré-équipée avec de nombreux helpers servant, par exemple, à faciliter la production de formulaires. Je vous renvoie à la documentation pour plus de détails à ce sujet. 9.5 LE COMPOSANT MODÈLE DU ZEND FRAMEWORK La technique dite Object-Relational Mapping (ORM) associe une couche orientée- objet à une base relationnelle sous-jacente. Elle est très importante pour réaliser le Modèle d’une application, puisque la plupart des objets du modèles sont persistants et doivent être sauvegardés dans la base de données. 9.5.1 L’ORM du Zend Framework Zend propose un ORM pour établir la correspondance entre la base et le code PHP. Cet ORM est moins puissant (du moins à l’heure où ces lignes sont écrites) que d’autres comme Ruby On Rails ou Hibernate, mais il gagne en simplicité et peut- être en performances. Cela constitue une manière élégante de cacher la structure relationnelle et de s’épargner dans de nombreux cas (mais pas tous) l’expression de requêtes SQL répétitives. L’ORM du ZF ne s’appuie pas sur de longs documents de configuration XML. Il se contente de réclamer quelques définitions légères dans des classes dédiées, et fournit ensuite des mécanismes sympathiques de parcours dans la base de données en suivant les liens définis par les clés primaires et étrangères. Toutes les classes ORM d’une application doivent hériter de l’une des trois classes abstraites suivantes. 1. Zmax_Db_Table_Abstract assure la correspondance avec les tables de la base ; 380 Chapitre 9. Introduction au Zend Framework 2. Zmax_Db_Rowset_Abstract eassure la correspondance avec les ensembles de lignes (autrement dit, les résultats de requêtes) ; 3. Zmax_Db_Row_Abstract assure la correspondance avec les lignes d’une table ou d’un résultat de requête. Comme leur nom l’indique, ces classes sont abstraites ;onnepeutdoncpas les instancier directement. Il faut fournir une classe concrète, héritant de Zmax_Db_Table_Abstract, pour chaque table intervenant dans le modèle ORM de l’application. 9.5.2 Le modèle ORM de l’application Le premier exemple est la classe Artiste, assez simple à définir puisqu’elle n’a pas de clé étrangère la liant à une autre table dans notre modèle de données. La correspondance est définie dans un fichier Artiste.php situé dans application/models. Exemple 9.8 zscope/application/models/Artiste.php : Le modèle de la table Artiste <?php class Artiste extends Zend_Db_Table_Abstract { protected $_name = ’ Artiste ’ ; protected $_primary = ’id ’ ; // Pas d’auto−incrémentation protected $_sequence = false ; } Cet exemple représente la correspondance minimale d’une classe sous-typant Zmax_Db_Table_Abstract. Les propriétés suivantes doivent être définies : 1. $_name est le nom de la table ; 2. $_primary est le nom de la clé primaire (un tableau s’il y a plusieurs attri- buts) ; 3. $_sequence est à true (par défaut) si la clé est auto-incrémentée ; rappelons que pour des raisons de portabilité aucune de nos clés n’est auto-incrémentée, mais vous pouvez omettre cette propriété et lui laisser sa valeur par défaut si vous choisissez l’auto-incrémentation. La clé primaire peut être obtenue directement de la base si elle n’est pas précisée (comme nous l’avons fait dans la classe TableBD implantant le modèle de notre MVC light). La faire figurer explicitement facilite la compréhension de la classe ORM. Voyons maintenant un exemple pour la table Film, dans laquelle figurent deux clés étrangères, l’une vers la table Artiste (le metteur en scène) et l’autre pour le pays. Pour simplifier, nous ne donnons la correspondance ORM que pour la première. 9.5 Le composant Modèle du Zend Framework 381 Exemple 9.9 zscope/application/models/Film.php : le modèle de la table Film <?php class Film extends Zend_Db_Table_Abstract { protected $_name = ’Film ’ ; protected $_primary = ’id ’ ; // Pas d’auto−incrémentation de la clé protected $_sequence = false ; // Référence à la table Artiste protected $_referenceMap = array ( "Realisateur" => array ( // Le "rôle" de l ’association "columns" => ’ id_realisateur ’ , // La clé étrangère "refTableClass" => "Artiste" , // La classe ORM de la table référencée "refColumns" => "id", // La clé étrangère référencée ) ); } Le tableau $_referenceMap contient un élément pour chaque table référencée par une clé étrangère. Au niveau de l’ORM, on ne donne pas la référence à des tables, mais aux classes ORM qui les encapsulent. Ici, on fait référence à la classe Film définie précédemment. Le but est bien d’avoir un modèle d’objets se référençant les uns les autres, en dissimulant les accès à la base de données. Chaque élément de $_referenceMap est lui-même un tableau donnant l’infor- mation définissant le lien entre les deux tables sous-jacentes. Elle doit permettre la reconstitution de la jointure pour calculer le lien entre les lignes des deux tables. On retrouve e toutes les informations de la clause FOREIGN KEY en SQL. Comme $_referenceMap est un tableau associatif, on donne un nom à l’as- sociation qui n’est pas nécessairement le nom de la table référencée, mais désigne plutôt le rôle de cette dernière dans l’association. Ici, l’entité référencée dans la table Artiste est le réalisateur du film, et ce rôle apparaît explicitement comme nom de l’association. On peut trouver plusieurs clés étrangères vers la même table, qu’il faut distinguer par un nom spécifique. Le dernier exemple que nous donnerons montre la correspondance pour une association plusieurs à plusieurs. C’est la table Role qui établit cette association entre les films et leurs acteurs dans la base de données. Au niveau des classes ORM, nous avons besoin d’une classe Role définie comme suit : Exemple 9.10 zscope/application/models/Role.php : le modèle de la table Role <?php class Role extends Zend_Db_Table_Abstract 382 Chapitre 9. Introduction au Zend Framework { protected $_name = ’Role ’; protected $_primary = array( ’id_film ’ , ’id_acteur ’); // Pas d’auto−incrémentation protected $_sequence = false ; // Référence au film et à l ’artiste protected $_referenceMap = array ( "Film" => array ( "columns" => ’ id_film ’ , // Nom de la clé étrangère "refTableClass" => "Film" , // Classe de la table référencée "refColumns" => "id" // Clé primaire référencée ), "Artiste" => array ( "columns" => ’id_acteur ’ , // Nom de la clé étrangère "refTableClass" => "Artiste" , // Classe de la table référencée "refColumns" => "id" // Clé primaire référencée ), ); } On met en œuvre les mêmes principes que précédemment avec le tableau $_referenceMap, qui contient cette fois deux entrées. Une nouvelle application doit non seulement définir le schéma relationnel avec SQL, mais également le modèle des classes ORM. Il ne semble pas exister à l’heure actuelle d’outil pour engendrer automatiquement les classes à partir des tables, mais cela viendra sûrement. Soulignons que les classes ORM héritent d’un ensemble de fonctionnalités pour gérer les échanges avec la base de données, mais qu’elles consti- tuent aussi une place de choix pour implanter la « logique métier » de l’application. Dans notre cas cette logique est limitée car notre application est essentiellement orientée vers l’exploitation d’une base de données, sans traitement complexe. En général, le modèle comprend des méthodes déterminant le comportement fonction- nel, « métier », des objets, en plus de leur caractère persistant. Dernière remarque avant de passer à l’exploitation des fonctionnalités de persis- tance : ces classes sont des classes concrètes qui peuvent être instanciées en objets qui communiquent avec les tables de la base. Elles ont donc besoin d’une connexion. Celle-ci n’apparaît pas ici, car elle est définie une fois pour toutes par l’appel à setDefaultAdapter() dans le fichier index.php. . est de créer une sous-classe MaVue de Zend_View et d’y placer ces méthodes. Pour éviter cette démarche un peu lourde, le Zend Framework permet d’implanter les méthodes ajoutées sous forme de helper. comprend des méthodes déterminant le comportement fonction- nel, « métier », des objets, en plus de leur caractère persistant. Dernière remarque avant de passer à l’exploitation des fonctionnalités de. s’appuie pas sur de longs documents de configuration XML. Il se contente de réclamer quelques définitions légères dans des classes dédiées, et fournit ensuite des mécanismes sympathiques de parcours