Table des matières
Zend Framework
Programmer's Reference Guide : fr en
Sources de documentation
sur developpez.net/.com : Accueil Cours, FAQ, Forums
- Les cours de Julien Pauli sur developpez.com sont très pertinents (sécurité, ZendFramework, …).
- le Zend Framework Francophone: http://www.z-f.fr
- http://mikaelkael.fr/ pour la traduction fr du guide de référence.
- Online resources for Zend Framework by Robert Basic
- Les méthodes et classes Fast_X de http://sekaijin.ovh.org/ (Fast_Action, Fast_Controller_Action, Fast_Config, …)
QuickStart
MVC:
- (fr) Plugins et helpers du MVC du Zend Framework sur kitpages.fr
- Create a modular application with Zend Framework by Jeroen Keppens on 2009-06-16
Articles
- Using a Dependency Injection Container with Zend_Application , Benjamin Eberlei, 2009-06-16
- PHP Performance Tips from Stas Malyshev: On his blog, Stas Malyshev (Core Contributor to PHP and Zend Employee) has posted a list of PHP Performance tips that he wants novices to know about. He realized that while he had previously panned a post by Google about PHP Performance of having lots of incorrect or misleading information, but that he never gave good substitute advice himself.
- Building a Zend Modular CMS System (JQuery, BB Code, Navigation and Blocks, TinyMCE, …)
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:
- Cache: Information on Zend_Cache and APC.
- Database: Full listing of SQL queries and the time for each.
- Exception: Error handling of errors and exceptions.
- File: Number and size of files included with complete list.
- Html: Number of external stylesheets and javascripts. Link to validate with W3C.
- Memory: Peak memory usage, memory usage of action controller and support for custom memory measurements.
- Registry: Contents of Zend_Registry
- Time: Timing information of current request, time spent in action controller and custom timers. Also average, min and max time for requests.
- Variables: View variables, request info and contents of $_COOKIE and $_POST
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:
- Zend_Controller_Front - manages the overall workflow.
- Zend_Controller_Request*- accessors for controllers and actions (and status .. e.g. already dispatched)
- Zend_Controller_Router - exactly once per request, calculates correct controllers and actions based on environment in Zend_Controller_Request
- Zend_Controller_Dispatcher - transfers flow of execution to controllers and actions in request object (Zend_Controller_Request*). Process repeats until no more actions are scheduled.
- Zend_Controller_Action* - userland controller classes containing userland actions
- Zend_Controller_Response* - contains the output of the executed actions
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:
- Plugin FrontController anti boucles infinies de dispatching (Eviter les boucles infinies de dispatching dans un modèle MVC à contrôleur frontal)
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 :
- Automatiser le rendu des layouts lorsqu'ils sont utilisés avec les composants MVC du Zend Framework.
- Fournir un cadre à part entière pour les variables du layout, au même titre que les variables de vue.
- Permettre la configuration du nom des layouts, la recherche des scripts leurs correspondant (inflexion), ainsi que leurs chemins d'accès.
- Permettre de désactiver les layouts temporairement, changer leur configuration ; tout ceci depuis les contrôleurs ou les scripts de vue.
- Utiliser les mêmes règles de résolution (inflexion) que le ViewRenderer, mais sans empêcher de les personnaliser à part.
- Une intégration sous forme d'aides/plugin dans le modèle MVC de Zend Framework.
Zend_Layout permet d'être utilisé de manière plus pointu. Vous pouvez agir sur ces éléments :
- Objet de vue personnalisé. Zend_Layout accepte tout objet de vue implémentant l'interface Zend_View_Interface.
- Plugin contrôleur frontal personnalisé. Zend_Layout est livré avec un plugin qui rend le layout automatiquement avant de renvoyer la réponse (utilisation MVC). Vous pouvez injecter votre propre plugin.
- Aide d'action personnalisée. Zend_Layout est livrée avec une aide d'action qui devrait en théorie suffire dans la majorité des cas. C'est un proxy vers l'objet Zend_Layout. Vous pouvez cependant utiliser votre propre classe d'aide.
- Résolveur de chemin de script personnalisé. Zend_Layout vous permet d'utiliser votre in-flecteur pour la résolution des scripts de layout ou de modifier l'inflecteur par défaut.
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.
Voir:
Zend_Db
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:
- Plugins et helpers du MVC du Zend Framework sur kitpages.fr
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:
- Plugins et helpers du MVC du Zend Framework sur kitpages.fr
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_View
PhpTAL
Discussion sur l'usage de PhpTAL comme Zend_View :
Zend_Form
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> </dt> <dd> <input type="submit" name="envoyer" id="envoyer" value="envoyer" /> </dd> </dl> </form>
Bootstrap
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
Aller plus loin
Bootstrap and other startup
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
- Another idea for using models with forms 07/01/2009
- Using Zend_Form in Your Models 22/12/2008
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:
- Gestions des exceptions intégrées dans MVC avec le plugin ErrorHandler (présentation du plugin “ErrorHandler” livré avec ZF).
Zend_ACL
Articles :
- Lier les ACLs aux contrôleurs et objets métiers le 2009-07-30 par Julien Pauli
- Applying ACLs to Models (2008-12-04): http://weierophinney.net/matthew/archives/201-Applying-ACLs-to-Models.html
Zend_Db
Diverses fonctionnalités
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 ?
et voir aussi
- “De la granularité des actions” qui traite notamment de la redirection entre actions (après un add, un save, …)
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:
- le couple plugin / aide d'action ActionStack.
voir aussi:
- les segments …
Wysiwyg editor integration
Use of FCKeditor :
- http://www.nabble.com/FCKEditor-and-Zend_Form-integration-td19688738.html (2008-11) integrate with Zend_Form.
- http://www.z-f.fr/forum/viewtopic.php?id=1874 intégration php (2008-09)
- http://www.z-f.fr/forum/viewtopic.php?id=1343 intégration javascript avec JQuery (2008-06)
Use of TinyMCE :
- Zend Framework TinyMce View Helper (2009-07-28)
Zend Tree / Treeview
Pas trouvé …
- Zend_Tree Proposal, no change since 2007
- http://www.berthou.com/us/2008/03/27/phptliste-an-opensource-treeview-in-php/ Berthou's Php treeview (not a Zend component). Voir discussion
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.