Nous aborderons donc les thèmes suivant:

  • Zend_Application
  • Zend_Controller
  • Zend_View
  • Zend_Layout
  • Zend_Db
  • Zend_Form
  • Zend_Auth
  • Zend_Acl
  • Zend_Navigation
  • Zend_Dojo

Introduction

Il faut savoir que Zend Framework n’est pas un framework tout à fait comme les autres, il est d’ailleurs souvent nommé framework « brique » en comparaison aux autres frameworks plus « englobant ».

Il a la particularité de fournir un ensemble de composants php5 appelés aussi packages (petit clin d’œil aux adeptes de Java !) faiblement couplés donc ayant de faibles dépendances les uns envers les autres. Il est donc possible d’utiliser individuellement la plus part des composants dans un contexte différent d’une application « full ZF » comme par exemple dans une application non-MVC ou dans un autre framework (cf: Symfony).

Là où un autre framework fourni et impose une structure pour votre logique applicative, ZF lui vous propose des outils et des solutions pour développer votre application de manière plus extensible et ajustée à vos besoins.

Pour illustrer cela de manière simple nous allons faire une excursion en montagne !

Il y a toujours deux types de randonneurs:

  • les randonneurs normaux: ceux qui prennent un guide pour se concentrer juste sur les choses à voir et à faire, non sur comment y aller.
  • les randonneurs ZF: ceux qui préfère prendre un plan des chemins de randonné à l’office du tourisme et créer leur propre visite guidée personnalisée (c’est plus long mais on fait ce que l’on veux).

Il est clair que le choix d’un framework doit être motivé par les besoins et le temps assigné au projet. Reprenons notre exemple, pour un weekend ponctuel en montagne il est préférable de prendre un guide et ne rien rater d’important, alors que pour une semaine tout les ans ça commence à être discutable.

ZF à des avantages mais aussi des inconvénients, en contrepartie d’une grande souplesse et d’une grande maniabilité de votre code, il faudra bien souvent coder vos propres outils là ou d’autres frameworks proposeraient nativement des solutions.

Maintenant que les lecteurs adeptes de visites guidées nous ont quittés pour se renseigner sur Symfony (excellent framework français d’ailleurs ), nous pouvons commencer !

Prés-requis

Pour ne pas vous perdre en cour de route, il est conseillé d’avoir de bonnes notions en :

Garder à porté de clic la “magnifique” doc en ligne de Zend, elle sera un outil indispensable dans vos projets ZF.

Le projet

L’application que nous allons réaliser permettra l’affichage et la gestion d’articles (CRUD simple) via l’utilisation d’une base de données.

Nous définirons trois types d’utilisateurs:

  • public : personne non-identifiée
  • rédacteur : rédaction d’articles
  • admin : publication et gestion des membres

Rien de très palpitant mais amplement suffisant pour introduire les notions qui nous intéressent. Nous utiliserons l’arborescence suivante qui est en fait l’arborescence non-modulaire par défaut prise en charge automatiquement par ZF. Je vous conseille de la garder en tête car j’y ferais assez souvent référence par la suite.

arbo-debuter-zend

Un peu de théorie

Le MVC

ZF est basé sur le design pattern MVC. Pour ceux qui ne sont pas encore bien familiarisés avec ce design pattern, je vais essayer de résumer les choses et mettre en parallèle les composants ZF associés.

mvc
Le modèle MVC en image (source Symfony)

Le contrôleur frontal

Dans la famille des contrôleurs le premier qui doit retenir votre attention, c’est le contrôleur frontal, il est le point d’entrée de l’application. C’est lui qui analyse les requêtes client, orchestre la distribution et renvoi la réponse.

Il implémente deux design pattern:

Dans ZF nous n’utiliserons pas directement la classe Zend_Controller_Front mais un composant de plus haut niveau nommé Zend_Application. Il utilisera le fameux Bootstrap pour configurer l’environnement d’une manière plus simple et malléable.

Les contrôleurs d’actions

Le motif actionController sert à factoriser le traitement en regroupant les actions par entité logique.

Ainsi le contrôleur frontal va déléguer les traitements spécifiques à chaque requête aux contrôleurs d’actions concernés.

Dans ZF, cela se traduit par l’utilisation de la classe Zend_Controller_Action dont tous nos contrôleurs applicatifs hériteront.

Les modèles

Toute application manipule des données, qu’elles soient de type texte, html, xml, issues d’une base de données, etc. Le modèle va permettre l’encapsulation de ces données et va fournir à notre application une liste de méthodes pour y accéder en lecture comme en écriture. Cette abstraction va nous permettre de traiter et d’assurer l’intégrité des données.

Dans ZF, l’utilisation la plus courante passe par le composant Zend_Db_Table qui est un ORM (partiel) pour l’accès aux bases de données.

Les vues

Comme sont nom l’indique une vue est ce que l’utilisateur voit, l’interface avec laquelle il interagit.

Typiquement dans une application web il s’agira du code HTML et Javascript.

La vue va recevoir les données traitées par le contrôleur et les présenter de manière à être compréhensible pour l’utilisateur. Sont rôle est aussi de permettre à l’utilisateur de réaliser des actions.

ZF met à notre disposition le composant Zend_View permettant de manipuler la partie visuelle de l’application tout en la gardant bien séparée des modèles et contrôleurs.

Fonctionnement du Zend Framework

Par défaut ZF impose une convention de nommage, elle permet le chargement automatique par l’autoloader des classes de manière simple et souple et se définie de la façon suivante:

En remplaçant le « _ » par « / » vous retrouverez donc le chemin du fichier de la classe utilisée. Prenons l’exemple du composant Zend_View, il fait référence à la classe du même nom à l’emplacement Zend/View.php.

Pour appeler ce composant:

$myView = new Zend_View();

Ainsi, plus besoin d’utiliser «include_once» ou «require_once», c’est ZF qui s’en occupe !

Du coté de notre logique applicative (répertoire « application »), certaines conventions de nommage sont aussi à respecter :

Les contrôleurs

Nous les mettrons dans le répertoire « controllers » et se nommeront NameController.php La classe devra étendre Zend_Controller_Action Les méthodes devront être nommées nameAction()

Les modèles

Nous les mettrons dans le répertoire « models » Il n’y a pas d’héritage obligatoire Pas de convention de nommage spécifique si ce n’est celle de l’autoloader

Les vues

Nous les mettrons dans le répertoire « views » Elles auront l’extension .phtml Chaque contrôleur aura son répertoire de vues, views/controller/ Chaque action du contrôleur aura sa vue views/controller/action-name.phtml

L’extension .phtml est l’équivalent de .php mais permet une meilleure lisibilité au niveau de la séparation MVC.

C’est bien sympathique des conventions mais elles vont nous servir à quoi me direz-vous ?!…
Et c’est là que la magie de l’autoloader prend tout son sens !
Avec ces conventions, l’appel :

http://www.mysite.fr/controller-name/action-name

va directement exécuter l’action actionNameAction() du contrôleur ControllerNameController et faire le rendu associé.

Pour la gestion des requêtes GET nous utiliserons le même procédé:

http://www.mysite.fr/controller-name/action-name/param1/value/paramX/value

Plutôt simple non ?

Conclusion

Nous avons vu ici les bases théoriques nécessaires pour une bonne compréhension du fonctionnement globale d’une application MVC et tout particulièrement du Zend Framework.

Cet article ne se veut pas exhaustif, mais j’espère vous avoir donné envie de poursuivre l’expérience que sera la réalisation du projet. N’hésitez pas à poster vos petits commentaires et remarques diverses, je tenterai d’y répondre le plus rapidement possible.

Le prochaine article sera donc consacré à la mise en place d’un projet ZF et plus précisément à l’utilisation du bootstrap.