Table des matières

Zend Framework

Zend Framework

http://framework.zend.com/

Programmer's Reference Guide : fr en

Comparaison Zend_Framework et Symfony

Etude perso

Sources de documentation

sur developpez.net/.com : Accueil Cours, FAQ, Forums

QuickStart

MVC:

Articles

Plugins

Web Debug Bar

ZFDebug

ZFDebug, previously known as Scienta ZF Debug Bar.

The available plugins at this point (v1.5 - 2009-05-21) are:

Project site on code.google.com.

Ze Framework

La convention “Package/SousPackage/Fichier.php” qui donnera “class Package_SousPackage_Fichier”.

Front Controller

Le processus de contrôleur frontal est un design pattern très connu qui s'intègre dans un modèle MVC. Le but du FC est de prendre en charge la totalité du traitement de la requête cliente. Pour ceci, le FC joue le rôle de chef d'orchestre, c'est d'ailleurs un singleton, à juste titre. Il va faire intervenir beaucoup d'objets, et va les faire jouer ensemble. On notera un objet de requête, un objet de réponse, un ensemble d'objet routeurs, un dispatcheur, un ensemble de contrôleurs dits “d'action”, des aides aux actions (Action Helpers), puis des plugins et un objet conteneur de plugins. Notez que FC ne touche pas à l'objet de vue.

Controller Workflow Summary:

Le processus complet du MVC de Zend Framework peut être résumé à ce plan là : 

 1. -FC initialise les plugins, le router, et le dispatcher
 2. -FC execute routeStartup() pour tous les plugins qui lui sont envoyés
 3. -FC execute le routeur pour récupérer un objet $request correspondant à un module, controller, action
 4. -FC execute routeShutdown() pour tous les plugins qui lui sont envoyés
 5. -FC execute dispatchLoopStartup() pour tous les plugins qui lui sont envoyés
 6. -FC entre dans la boucle de dispatching
 7. ---FC marque {{$request}} comme dispatchée ( isDispatched() = TRUE )
 8. ---FC execute preDispatch() pour tous les plugins qui lui sont envoyés
 9. ---FC demande au dispatcher de dispatcher la requête $request
10. ------dispatcher instancie le contrôleur d'action
11. ------dispatcher marque la requête $request comme dispatchée
12. ------dispatcher execute dispatch() sur le contrôleur d'action
13. ---------le contrôleur d'action execute son init()
14. ---------le contrôleur d'action execute notifyPreDispatch() pour tous les helpers qui lui sont passés
15. ---------le contrôleur d'action execute son preDispatch()
16. ---------le contrôleur d'action execute la requête $action (PRINCIPAL)
17. -----------A ce stade on peut demander à FC d'abandonner immédiatement tout le processus si une exception est envoyée
18. ---------le contrôleur d'action execute son postDispatch()
19. ---------le contrôleur d'action execute notifyPostDispatch() pour tous les helpers qui lui sont passés
20. ------FC execute postDispatch() pour tous les plugins qui lui sont envoyés
21. ------la boucle de dispatching recommence si la requête n'est pas marquée comme dispatchée (redirection)
22. -FC sort de la boucle de dispatching, le traitement de l'action est terminé
23. -FC execute dispatchLoopShutdown() pour tous les plugins qui lui sont envoyés
24. -FC retourne $response ou l'affiche directement

Voir:

Zend_Layout

Zend_Layout utilise le design pattern Two-Step View, ce qui permet d'encapsuler le contenu d'une vue dans une autre, généralement appelée template. D'autres projets les appellent aussi layouts, ainsi Zend Framework utilise ce terme.

Les principales caractéristiques de Zend_Layout sont :

Zend_Layout permet d'être utilisé de manière plus pointu. Vous pouvez agir sur ces éléments :

Zend_Layout n'est pas un composant de MVC. Son arborescence est telle qu'il n'est pas intégré dans le modèle MVC, il peut donc être utilisé en dehors. Parallèlement, le modèle MVC peut être utilisé sans Zend_Layout.

Zend_Layout Diagramme de séquence simplifié

Voir:

Zend_Db

Zend_Db class diagram

Voir:

Plugins

Le modèle MVC de ZF regorge de designs patterns et parmi eux, on note de nombreux proxies, qui je le rappelle permettent de déléguer le traitement entier d'un processus à une autre classe. Le contrôleur frontal de Zend Framework utilise le motif proxy via des plugins. Un plugin est une classe que l'on peut injecter dans le frontController, et qui va avoir un but précis et agir au sein même du processus de dispatching.

<note>Les plugins sont principalement destinés à gérer les problèmes de routage. Les helpers sont utilisés pour tous les traitements que vous seriez tentés de recopier dans toutes vos actions. Un bon article sur le sujet: Plugins et helpers du MVC du Zend Framework sur kitpages.fr </note>

Voir:

Helpers

Helpers: aides d'action.

<note>Les plugins sont principalement destinés à gérer les problèmes de routage. Les helpers sont utilisés pour tous les traitements que vous seriez tentés de recopier dans toutes vos actions. Un bon article sur le sujet: Plugins et helpers du MVC du Zend Framework sur kitpages.fr </note>

Voir:

Zend_Config

Permet de lire un fichier de configuration au format .INI. Gère l'héritage de section ([section child : section root]) et de clé (parentkey.childkey)

Zend_Config est un design pattern Composite.

Zend_Config class diagram

Zend_View

Zend_View class diagram

PhpTAL

Discussion sur l'usage de PhpTAL comme Zend_View :

Zend_Form

Doc Zend_Form fr en.

Exemples

Exemple 01

Le code php : 

$formAction = $_SERVER['REQUEST_URI'] ;
 
$form = new Zend_Form();
// afin qu'il renvoie vers la même page que celle l'ayant crée, ceci simplifie les traitements.
$form->setAction($formAction)
	->setAttrib('id', 'dvp-form')
	->setDescription('formulaire exemple developpez.com')
	->setEnctype(Zend_Form::ENCTYPE_URLENCODED)
	->setLegend('légende')
	->setMethod('POST')
	->setName('dvp-form')
	->setView( $this->view )
	;
 
$text = new Zend_Form_Element_Text('un champ texte');
$text->setRequired(true)
     ->setErrorMessages(array('required'=>'Element requis'))
     ->setLabel('Voici un champ texte :')
     ->setDescription('Ce champ est là à titre informatif pour le tutoriel')
     ->setAttrib('size','70');
 
$envoyer = $form->createElement('submit','envoyer');
 
$form->addElements(array($text,$envoyer));

le code html obtenu après post du formulaire sans avoir renseigné le champs 'unchamptexte' (required not satisfied) : 

<form id="dvp-form" enctype="application/x-www-form-urlencoded" action="/ZendFramework/Essais01/html/FormOne" method="post">
 <dl class="zend_form">
  <dt>
   <label for="unchamptexte" class="required">Voici un champ texte :</label>
  </dt>
  <dd>
   <input type="text" name="unchamptexte" id="unchamptexte" value="" size="70" />
   <ul class="errors">
    <li>Element requis</li>
   </ul>
   <p class="description">Ce champ est là à titre informatif pour le tutoriel</p>
  </dd>
  <dt>&nbsp;</dt>
  <dd>
   <input type="submit" name="envoyer" id="envoyer" value="envoyer" />
  </dd>
 </dl>
</form>

Bootstrap

Writing module bootstraps

Performance

Lire “Annexe C. Zend Framework Performance Guide” du guide de référence du programmeur. Les domaines d'optimisation traités sont: “Chargement des classes”, “Zend_Db Performance”, “Internationalisation”, “View rendering”.

Benchmarking Zend Framework loader Posted by Stas 2008-05-16

Without bytecode cache:
require_once Zend_Loader
php5.2 4.42 4.42
php5.3 4.96 4.97
With bytecode cache:
require_once Zend_Loader
php5.2 63.04 56.62
php5.3 61.28 55.52

The numbers are requests per second, so more is better. Test run on Linux dual 2GHz AMD

Voir /informatique/php/performance

Aller plus loin

Bootstrap and other startup

Mise en place d’un bootstrap amélioré avec Initializer

Testing

Automatic testing of MVC applications created with Zend Framework by Alex Netkachov on 2007-03-20

Voir tests

Zend_Form

Créer un formulaire de login réutilisable basé sur Zend_Form par Julien Pauli (09/02/2009)

Zend_Form est un composant touffu, mais très puissant. Plus encore que d'autres composants du Zend Framework , Zend_Form a été prévu pour être étendu. Nous allons voir comment créer un LoginForm, basé sur Zend_Form, qui comme son nom l'indique, permet la connexion d'une personne grâce à un couple login/password avec une vérification de l'identité via une base de données.

Using Zend_Form in Your Models

Database backed Zend_Form elements

http://codeutopia.net/blog/2009/03/09/database-backed-zend_form-elements/

A relatively common task when working with forms is filling select boxes or checkbox and radiobutton lists from a database.

It’s not very tricky to query a database, and fill a Zend_Form element’s possible values from the resultset, but it can be quite boring and extraneous code…

We could also create an element which we can give some SQL, and it’ll fill itself automatically! This way you can even define database-backed elements in XML or INI configuration files.

The main benefits of this approach show when you want to create forms quickly, for example when you’re still developing your application. With this, you can easily define where the data in the element comes from without having to write code to query the database manually.

This is also where the main drawback lies: because each element of this kind will perform an SQL query, you may suddenly find a lot of queries, depending on the setup.

As an added bonus, this also works with Zend_Config based forms! If you like building your forms in XML or INI files, you can use this element and define all this in the configuration. Just leave out the dbAdapter value, and remember to set a default adapter in Zend_Db_Table in your bootstrap or such - this is why we test it in the element’s code.

Implementing this for checkboxes or radios would follow a quite similar process - you’d just mainly change the class which is being extended.

Zend_Form decorators

http://codeutopia.net/blog/2008/08/07/zend_form-decorator-tips/

It seems a lot of people are struggling with Zend_Form decorators. They want to know how to modify the markup, but they can’t figure out how to do it with the bundled decorators or how to write their own.

Since I’ve done some decorator-stuff myself, I thought I’d share some tips on making the output a bit nicer. For example, how to make Zend_Form use <ul> and <li> tags instead of <dd>, <dt> and <dl>. I also wanted some inputs appear side by side (date from and date to in my case).

Learn what the bundled decorators do and which are required. You can do a lot of stuff with the decorators that are shipped with Zend Framework, for example the HtmlTag decorator can be used in most scenarios.

Also, learn the vital decorators: For forms, you’ll usually need Form and FormElements, for DisplayGroups FormElements and FieldSet and for elements, ViewHelper, Label and Errors. Without these decorators, the form won’t work very well - you could always make your own, but most of the time these basic ones should suffice.

With the decorators I listed above, you will get a very basic form; basically just the form element, the labels and the inputs - no dd, dt or such. From there, it’s easy to start building your own markup, which I will show later in this post.

Complex custom elements in Zend_Form

http://codeutopia.net/blog/2008/10/23/complex-custom-elements-in-zend_form/

I’ve sometimes needed custom elements in forms - say two fields for inputting two numbers. For something simple like that, adding two separate elements usually suffice, but when one of my clients wanted a field with multiple checkboxes, but only specific pairs could be selected, it started getting too complex.

Until then, I had kind of avoided making those custom elements, as there didn’t seem to be much information on them in the Zend_Form documentation. I decided it was time to find out how to do it!

The alternatives would be creating custom view helpers to output the custom form elements, and using the viewscript decorator. Creating a custom view helper would also require a custom form element class, and it would be a bit tricky.

The viewscript decorator can be used to easily output elements with totally custom markup. You can even have the viewscript insert some JavaScript code into the inlineScript or headScript helpers. You could do this with just one of the default form elements, but in my case I required a custom element too.

I think the viewscript approach is the most flexible and simplest to implement, so I chose to go with that.

Gestion des erreurs

par Julien Pauli:

Handling errors in Zend Framework

Zend_ACL

Articles :

Zend_Db

Diverses fonctionnalités

Zend_Db_Table Enhancements

Gestion d’un cache SQL sous Zend Framework le 2008-08-23 par Stéphane Legrand

Zend_Db_Table and Nested Set (données hiérarchiques)

Zend_Db_Table Enhancements : http://www.virgentech.com/blog/view/id/4.

Extending Zend_Db_Table to create NestedSet models (2008-07-13): http://dev.iordanov.net/archives/category/database

Zend_Generator_Orm Component Proposal

Au sein du Framework Zend, vous avez besoin de définir une classe dans le répertoire 'models' qui étend Zend_Db_table_Abstract pour chaque table de votre base de données que vous voulez accéder. Pour chacune de ces classes, vous avez besoin de déclarer des variables protected comme le nom de la table dans $_name, les clé(s) primaire(s) dans $_primary, les tables dépendantes dans $_dependentTables, les tables liées dans $_referenceMap, etc. Au final, vous passez un temps fou à créer les mêmes choses et, à chaque modification de votre base de données, vous devez encore éditer vos modèles! Zend_Generator_Orm est un composant simple qui lit l'architecture de votre base de données et génères automatiquement les modèles Zend. Ce générateur de classes fonctionne que ce soit en création ou en update tout en conservant les méthodes implémentées par l'utilisateur.

http://framework.zend.com/wiki/display/ZFPROP/Zend_Generator_Orm+-+Thomas+VEQUAUD

Zend Framework DataGrid

Zend Framework DataGrid is a project / component written in PHP5, specially developed to work with Zend Framework, aims to generate grids or list from a Data Source such Zend_Db_Table, Zend_Db_Select, Zend_Db_Adapter, Propel, Array, and so on. With features like sort columns (sort / order by), pagination and an appropriate render depending on the type of column.

The project link : http://code.google.com/p/zend-framework-datagrid/

Zend_Controller_Action

Gestion dynamique de la navigation (historique côté serveur)

En imaginant que mon utilisateur active l’action « éditer un client » dans l’écran je vais lui proposer un lien permettant d’annuler cette opération à n’importe quelle étape du processus d’édition. Que mettre comme valeur dans ce lien ? En effet, à priori, je ne sais pas dans quel état il était avant d’activer la fonctionnalité. Généralement ne sachant pas vers quoi le rediriger on l’envoie sur un écran d’accueil, un menu général. C’est plutôt frustrant. Où alors on s’arrange pour que cette fonctionnalité ne soit accessible que d’un seul endroit. Là encore c’est peu satisfaisant du point de vue de l’utilisateur. Il serait souhaitable d’annuler la fonctionnalité en cours et de revenir à celle qui précédait. Pour cela il est nécessaire de connaitre dynamiquement le point d’activation de la fonctionnalité. Par exemple depuis le menu principal, je peux rechercher puis éditer un client. Mais aussi lorsque je fais une facture (pour corriger une adresse par exemple). Mais si je permets à mon utilisateur d’activer les fonctions qu’il veut quant il veut, quand saurais-je que je peux nettoyer ma mémoire (session) des objets en cours ?

http://sekaijin.ovh.org/?p=31

et voir aussi

Zend_Layout

Rendre plusieurs actions

Rendre plusieurs contrôleur (par des views) dans le layout. Quand dans le layout on fait : 

$this->render(header.phtml);
$this->render(menu_gauche.phtml);
<div id ="content">
...
</div>
$this->render(footer.phtml);

Ce ne sont que des vues qui sont utilisées.

On aura plus souvent besoin de rendre des résultats d'action de contrôleur. La méthode :

Pour faire çà, il ya le Zend_Layout et la pile d'actions. (voir tuto du site qui explique tout çà)

Dans ton Layout, tu définis 3 segment (gauche, droite, center)
Et dans ton action ArticleControlleur::listeAction(), tu rend la vue de cette action dans le segment “center”
Tu ajoutes à ta pile d'action l'action ForumControlleur::lasttopicAction().
Une fois listeAction effectué, le dispartcher lancera lasttopicAction() et dedans tu rends la vue dans le segment “droite” du layout.

Voir:

voir aussi:

Wysiwyg editor integration

Use of FCKeditor :

Use of TinyMCE :

Zend Tree / Treeview

Pas trouvé …

Lister tous les contrôleurs d'une application

Iterate through the file system then use Reflections to gather the Methods (Actions) in a Controller. 

 require_once 'My/Class.php';
 $fileReflect = new Zend_Reflection_File('My/Class.php');
 $methods = $fileReflect->getClass('My_Class')->getMethods();
 var_dump($methods);

From fw-general@lists.zend.com :

Our front controller in ZF is an execution based front controller. This means that it first will determine what is being asked for, then simple attempt to execute it.
This is in contrast to a reflective front controller, where the Front Controller system would know what is available in the entire system prior to execution.
That said, you will more than likely have to get the module directory from the front controller, then iterate that to find the modules. Once you have the modules, you'll have to find the *Controller.php files inside the controller directory of each module. After that, if you want the actions, reflection is the best way to go: looking for any methods that are public and end in 'Action'.

Solution dans http://www.developpez.net/forums/d805986/php/outils/zend/zend-framework/mvc/lister-controleurs-dispo-application/

Je me suis écrit une classe Utils_ZFApplicationExplorer qui fait le boulot.

ZF & ORM

You should take a look at Doctrine 2. As Zend Entity it implements the JPA specification and is a true data mapper with models decoupled from Database completly.

Sur cette page http://www.doctrine-project.org/about, vous verrez que Benjamin Eberlei (auteur de Zend_Entity) est contributeur de Doctrine 2 et Guilherme Blanco est un contributeur habituel de ZF.