Previous Next

Migrer depuis des versions précédentes

L'API des composants MVC a changé plusieurs fois. Si vous avez débuté avec des versions antérieures de Zend Framework, suivez les recommandations suivantes pour migrer vos scripts afin d'utiliser la nouvelle architecture.

Migrer de la version 1.7.x vers 1.8.0 ou plus récent

Changement de la route standard

Comme les segments traduits ont été ajoutés dans la nouvelle route standard, le caractère @ est maintenant un caractère spécial au début d'un segment de route. Pour être capable de l'utiliser dans un segment statique, vous devez l'échapper en le préfixant avec un second @. La même règle s'applique aussi au caractère :.

Migrer de la version 1.6.x vers 1.7.0 ou plus récent

Changement dans l'interface Dispatcher

Les utilisateurs ont portés l'attention sur le fait que Zend_Controller_Action_Helper_ViewRenderer utilisait une méthode de la classe abstraite du distributeur standard qui n'était pas présente dans l'interface Dispatcher.La méthode suivante a donc été ajoutée pour s'assurer que les distributeurs personnalisés continueront à fonctionner avec les implémentations embarquées :

  • formatModuleName() : devrait être utilisé pour prendre un nom de contrôleur brut, comme un qui aurait été embarqué dans un objet requête, et pour le formater en un nom de classe approprié qu'une classe étendant Zend_Controller_Action pourra utiliser.

Migrer de la version 1.5.x vers 1.6.0 ou plus récent

Changement dans l'interface Dispatcher

Les utilisateurs ont porté à notre connaissance le fait que Zend_Controller_Front et Zend_Controller_Router_Route_Module utilisent tous les deux des méthodes du distributeur qui ne sont pas dans l'interface associée. Nous avons donc ajouté les trois méthodes suivantes pour s'assurer que les distributeurs personnalisés continueront à fonctionner avec les implémentations embarquées :

  • getDefaultModule() : retourne le nom du module par défaut.

  • getDefaultControllerName() : retourne le nom du contrôleur par défaut.

  • getDefaultAction() : retourne le nom de l'action par défaut.

Migrer de la version 1.0.x vers 1.5.0 ou plus récent

Bien que la plupart des fonctionnalités de base demeurent les mêmes, et que toutes les fonctionnalités documentées restent les mêmes, il existe une "fonctionnalité" particulière non documentée qui a changé.

Quand vous écrivez des URLs, la manière documentée d'écrire les noms d'action en notationCamel est d'utiliser un séparateur de mot ; ceux ci sont "." ou "-" par défaut, mais ils peuvent être configurés dans le distributeur. Le distributeur en interne transforme les noms d'action en minuscules, et utilise ces séparateurs de mots pour ré-assembler la méthode d'action en utilisant la notationCamel. Cependant, comme les fonctions PHP ne sont pas sensibles à la casse, vous pouvez toujours écrire les URLs en utilisant la notationCamel, et le distributeur les résoudra de la même manière. Par exemple, "notation-camel" deviendra "notationCamelAction" dans le distributeur, tandis que "notationCamel" deviendra "notationcamelAction" ; cependant, à cause de l'insensibilité à la casse de PHP, dans les deux cas cela exécutera la même méthode.

Ceci pose des problèmes avec le ViewRenderer lors de la résolution des scripts de vue. La manière canonique et documentée est que tous les séparateurs de mot sont convertis en tirets, et les mots en minuscules. Ceci crée un lien sémantique entre les actions et les scripts de vue, et la normalisation s'assure que les scripts peuvent être trouvés. Cependant, si l'action "notationCamel" est appelée et est résolue, le séparateur de mot n'est pas pour autant présent, et le ViewRenderer tente de résoudre un emplacement différent - "notationcamel.phtml" au lieu de "notation-camel.phtml".

Quelques développeurs se sont fondés sur ce "dispositif", qui n'a jamais été prévu. Plusieurs changements de l'arbre 1.5.0, cependant, l'ont fait de sorte que le ViewRenderer ne résout plus ces chemins ; le lien sémantique est maintenant imposé. A partir de maintenant, le distributeur impose la sensibilité à la casse dans les noms d'action. Ceci veut dire que la référence vers vos actions dans l'URL en utilisant la notationCamel ne résoudra plus les mêmes méthodes qu'en utilisant les séparateurs de mots (par ex., "notation-camel"). Ceci entraîne qu'à partir de maintenant le ViewRenderer honorera seulement les actions en "mots-séparés" lors de la résolution des scripts de vue.

Si vous constatez que vous comptiez sur ce "dispositif", vous avez plusieurs options :

  • Meilleure option : renommez vos scripts de vue. Pour : compatibilité ascendante. Contre : si vous avez beaucoup de scripts de vue basés sur l'ancien, comportement fortuit, vous aurez beaucoup de renommage à faire.

  • Seconde meilleure option : le ViewRenderer délégue maintenant la résolution des scripts de vue à Zend_Filter_Inflector ; vous pouvez modifier les règles de l'inflecteur pour ne plus séparer les mots d'une action avec un tiret :

    $viewRenderer =
        Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
    $inflector = $viewRenderer->getInflector();
    $inflector->setFilterRule(':action', array(
        new Zend_Filter_PregReplace(
            '#[^a-z0-9' . preg_quote(DIRECTORY_SEPARATOR, '#') . ']+#i',
            ''
        ),
        'StringToLower'
    ));

    Le code ci-dessus modifiera l'inflecteur pour ne plus séparer les mots avec un tiret ; vous pouvez aussi vouloir supprimer le filtre StringToLower si vous voulez que vos scripts de vues utilisent aussi la notationCamel.

    Si le renommage de vos scripts de vue est trop fastidieux ou nécessite trop de temps, ceci est la meilleure option avant de trouver le temps de le faire.

  • Option la moins souhaitable : vous pouvez forcer le distributeur à distribuer les noms d'action écrits en notationCamel avec un nouveau drapeau du contrôleur frontal, useCaseSensitiveActions :

    $front->setParam('useCaseSensitiveActions', true);

    Ceci vous permettra d'utiliser la notationCamel dans l'URL et de toujours faire résoudre la même action que si vous utilisez les séparateurs de mots. Cependant, ceci signifiera que les problèmes décrits ci-dessus interviendront tôt ou tard ; vous devrez probablement utiliser la deuxième option ci-dessus en plus de celle-ci pour que tout fonctionne correctement.

    Notez, de plus, que l'utilisation de ce drapeau déclenchera une notice indiquant que cette utilisation est dépréciée.

Migrer de la version 0.9.3 vers 1.0.0RC1 ou plus récent

Les principaux changements introduits dans la version 1.0.0RC1 sont l'ajout et l'activation par défaut du plugin ErrorHandleret de l'aide d'action ViewRenderer. Veuillez lire la documentation de chacun des éléments directement pour apprendre leur fonctionnement et quels effets, ils peuvent avoir sur vos applications.

Le plugin ErrorHandler est exécuté pendant postDispatch() vérifiant la présence d'exceptions, et redirigeant vers le contrôleur de gestion d'erreur spécifié. Vous pouvez le désactiver en réglant le paramètre noErrorHandler du contrôleur frontal :

$front->setParam('noErrorHandler', true);

L'aide d'action ViewRenderer automatise l'injection de vues dans les contrôleurs d'action en tant qu'autogénération des scripts de vues suivant l'action courante. Le principal problème que vous pourriez rencontrer intervient quand vous avez des actions qui ne rendent pas de scripts de vues ni ne font suivre ou redirige, alors ViewRenderer va tenter de rendre un script de vue basé sur le nom de l'action.

Il existe plusieurs possibilités pour mettre à jour votre code. Dans un premier temps, vous pouvez globalement désactiver ViewRenderer dans votre fichier d'amorçage du contrôleur frontal avant toute distribution :

// En considérant que $front est une instance de Zend_Controller_Front
$front->setParam('noViewRenderer', true);

Cependant, ceci n'est pas une bonne stratégie à long terme, car il apparaît aisément que vous devrez écrire plus de code.

Quand vous serez prêt à utiliser la fonctionnalité ViewRenderer, il y a plusieurs choses à vérifier dans votre code de contrôleur. Premièrement, regardez vos méthodes d'actions (les méthodes se terminant par "Action"), et déterminez ce que chacune d'elle réalise. Si rien de ce qui suit n'est réalisé, vous devrez réaliser des changements :

  • Appel de $this->render()

  • Appel de $this->_forward()

  • Appel de $this->_redirect()

  • Appel de l'aide d'action Redirector

Le changement le plus simple est la désactivation de l'auto-rendu pour cette méthode :

$this->_helper->viewRenderer->setNoRender();

Si vous trouvez qu'aucune de vos méthodes d'actions n'effectue de rendu, ne font suivre, ou redirige, vous pouvez préférer mettre la ligne suivante dans la méthode preDispatch() ou init() :

public function preDispatch()
{
    // désactive l'auto-rendu des scripts de vues
    $this->_helper->viewRenderer->setNoRender()
    // ... faire autre chose ...
}

Si vous appelez render(), et que vous utilisez la structure de dossier modulaire conventionnelle, vous voudrez modifier votre code pour utiliser l'auto-rendu :

  • Si vous rendez de multiples scripts de vues dans une seule action, vous n'avez rien à modifier.

  • Si vous appelez simplement render() sans aucun argument, vous pouvez effacer ces lignes.

  • Si vous appelez render() avec des arguments, et que vous ne réalisez pas ensuite d'exécution de code ou effectuez le rendu de scripts de vues multiples, vous pouvez changer ces appels par $this->_helper->viewRenderer().

Si vous n'utilisez pas la structure de dossier modulaire conventionnelle, il existe une variété de méthodes pour paramétrer le chemin de base des vues et les spécifications du chemin vers les scripts ainsi vous pourrez utiliser ViewRenderer. Veuillez lire la documentation de ViewRendererpour plus d'informations sur ces méthodes.

Si vous utilisez un objet de vue issu du registre, ou que vous personnalisez votre objet vue, ou que vous utilisez une implémentation de vue différente, vous pouvez vouloir injecter ViewRenderer dans cet objet. Ceci peut être réalisé facilement à tout moment.

  • Avant la distribution d'une instance de contrôleur frontal :

    // En considérant que $view a déjà été définie
    $viewRenderer = new Zend_Controller_Action_Helper_ViewRenderer($view);
    Zend_Controller_Action_HelperBroker::addHelper($viewRenderer);
  • A tout moment durant le processus d'amorçage :

    $viewRenderer =
        Zend_Controller_Action_HelperBroker::getStaticHelper('viewRenderer');
    $viewRenderer->setView($view);

Il existe plusieurs manières de modifier ViewRenderer, incluant le réglage d'un script de vue différent à rendre, la spécification d'un remplaçant pour tous les éléments remplaçables d'un chemin de script de vues (incluant le suffixe), le choix d'un segment nommé de la réponse à utiliser, et plus encore. Si vous n'utilisez pas la structure de dossier modulaire conventionnelle, vous pouvez tout de même associer différentes spécifications de chemin à ViewRenderer.

Nous vous encourageons à adapter votre code pour utiliser ErrorHandler et ViewRenderer puisqu'il s'agit maintenant de fonctionnalités natives.

Migrer de la version 0.9.2 vers 0.9.3 ou plus récent

0.9.3 introduit les aides d'actions. En lien avec ce changement, les méthodes suivantes ont été effacées puisqu'elles sont maintenant encapsulées dans l'aide d'action redirector :

  • setRedirectCode() à remplacer par Zend_Controller_Action_Helper_Redirector::setCode().

  • setRedirectPrependBase() à remplacer par Zend_Controller_Action_Helper_Redirector::setPrependBase().

  • setRedirectExit() à remplacer par Zend_Controller_Action_Helper_Redirector::setExit().

Lisez la documentation des aides d'actionspour plus d'informations sur la récupération ou la manipulation des objets "helper", et la documentation du helper redirectorpour plus d'informations sur le réglage des options de redirection (de même que pour les méthodes alternatives de redirection).

Migrer de la version 0.6.0 vers 0.8.0 ou plus récent

Pour les versions précédentes, l'utilisation basique des composants MVC reste la même :

Zend_Controller_Front::run('/chemin/vers/controleurs');

Cependant, la structure des dossiers a subi une réorganisation, certains composants ont été effacés, et d'autres ont été soit renommés soit ajoutés. Les changements incluent :

  • Zend_Controller_Router a été effacé en faveur du routeur de réécriture ("rewrite router").

  • Zend_Controller_RewriteRouter a été renommé en Zend_Controller_Router_Rewrite, et promu en tant que routeur standard fourni avec le framework ; Zend_Controller_Front l'utilise par défaut si aucun autre routeur n'est fourni.

  • Une nouvelle classe de route à utiliser avec le routeur de réécriture a été introduite, Zend_Controller_Router_Route_Module ; elle couvre la route par défaut utilisée par le MVC, et supporte les modules de contrôleurs.

  • Zend_Controller_Router_StaticRoute a été renommé en Zend_Controller_Router_Route_Static.

  • Zend_Controller_Dispatcher a été renommé en Zend_Controller_Dispatcher_Standard.

  • Les arguments de Zend_Controller_Action::_forward() ont changés. La signature est maintenant :

    final protected function _forward($action,
                                      $controller = null,
                                      $module = null,
                                      array $params = null);

    $action est toujours obligatoire ; si aucun contrôleur n'est spécifié, une action dans le contrôleur courant est considérée. $module est toujours ignoré à moins que $controller ne soit spécifié. Pour finir, tout $params fourni sera ajouté à l'objet requête. Si aucun contrôleur ou module n'est nécessaire, mais que des paramètres le sont, passez simplement NULL pour ces valeurs.

Migrer de la version 0.2.0 ou plus ancien vers 0.6.0

L'utilisation de base des composants MVC n'a pas changé ; vous pouvez toujours faire comme suit :

Zend_Controller_Front::run('/chemin/vers/controleurs');
/* -- créer un routeur -- */
$router = new Zend_Controller_RewriteRouter();
$router->addRoute('user', 'user/:username', array('controller' => 'user',
'action' => 'info'));

/* -- l'affecter à un contrôleur -- */
$ctrl = Zend_Controller_Front::getInstance();
$ctrl->setRouter($router);

/* -- régler le répertoire des contrôleurs et distribuer -- */
$ctrl->setControllerDirectory('/chemin/vers/controleurs');
$ctrl->dispatch();

Nous encourageons l'utilisation de l'objet Réponse pour agréger le contenu et les en-têtes. Ceci permet un basculement plus flexible entre les formats d'affichage (par exemple, JSON ou XML au lieu de XHTML) dans vos applications. Par défaut, dispatch() va effectuer le rendu de la réponse, envoyant à la fois les en-têtes et tout contenu. Vous pouvez aussi avoir le contrôleur frontal qui retourne la réponse en utilisant returnResponse(), et qui ensuite effectue le rendu de la réponse suivant votre propre logique. Une version future du contrôleur frontal peut mettre en application l'utilisation de l'objet Réponse via la » bufferisation de sortie.

Il existe beaucoup d'autres fonctionnalités qui étendent l'API existante, et celles-ci sont décrites dans la documentation.

Le changement le plus important auquel vous devrez faire attention apparaîtra quand vous tenterez de sous-classer les différents composants. La clé se trouve ci-dessous :

  • Zend_Controller_Front::dispatch() intercepte par défaut les exceptions dans l'objet réponse, et ne les affiche pas, afin d'éviter l'affichage d'information sensible du système. Vous pouvez surcharger ceci de différentes manières :

    • Régler throwExceptions() dans le contrôleur frontal :

      $front->throwExceptions(true);
    • Régler renderExceptions() dans l'objet Réponse :

      $response->renderExceptions(true);
      $front->setResponse($response);
      $front->dispatch();
      // ou :
      $front->returnResponse(true);
      $response = $front->dispatch();
      $response->renderExceptions(true);
      echo $response;
  • Zend_Controller_Dispatcher_Interface::dispatch() accepte maintenant et retourne un objet L'objet Requête au lieu d'un élément du distributeur.

  • Zend_Controller_Router_Interface::route() accepte maintenant et retourne un objet L'objet Requête au lieu d'un élément du distributeur.

  • Les changements de Zend_Controller_Action incluent :

    • Le constructeur accepte maintenant exactement trois arguments, Zend_Controller_Request_Abstract $request, Zend_Controller_Response_Abstract $response, et le tableau facultatif $params. Zend_Controller_Action::__construct() les utilise pour affecter la requête, la réponse, et les propriétés invokeArgs de l'objet, et si vous devez surcharger le constructeur, vous devez faire de même. La meilleure solution est d'utiliser la méthode init() pour réaliser toute configuration de l'instance, puisque cette méthode est appelée en tant que action finale du constructeur.

    • run() n'est plus défini en tant qu'élément final, mais n'est pas non plus utilisé par le contrôleur frontal ; son seul but apparaît lors de l'utilisation de la classe en tant que contrôleur de page. Il prend maintenant deux arguments facultatifs, un Zend_Controller_Request_Abstract $request et un Zend_Controller_Response_Abstract $response.

    • indexAction() ne nécessite plus d'être défini, mais est recommandé en tant qu'action par défaut. Ceci permet lors de l'utilisation de RewriteRouter et des contrôleurs d'action de spécifier différentes méthodes d'action par défaut.

    • __call() peut être surchargé pour gérer automatiquement les actions non définies.

    • _redirect() prend maintenant un second paramètre facultatif, le code HTTP à retourner avec la redirection, et un troisième paramètre optionnel, $prependBase, qui peut indiquer que l'URL de base enregistré avec l'objet requête peut être ajouté en tant que suffixe à l'URL spécifié.

    • La propriété _action n'existe plus. Cette propriété était un Zend_Controller_Dispatcher_Token, qui n'existe plus maintenant. Le seul but de cet élément est de fournir l'information concernant le contrôleur, l'action et les paramètres d'URL de la requête. Cette information est maintenant disponible dans l'objet requête, et peut être interrogé comme ceci :

      // Récupère le nom de controleur de la requête
      // L'accès se fait via : $this->_action->getControllerName().
      // L'exemple ci-dessous utilise getRequest(), bien que vous pourriez
      // accéder directement à la propriété $_request ;
      // l'utilisation de getRequest() est recommandée puisque la classe
      // parente peut surcharger l'accès à l'objet requête.
      $controller = $this->getRequest()->getControllerName();
      
      // Recupere le nom de l'action de la requete
      // L'acces se fait via : $this->_action->getActionName().
      $action = $this->getRequest()->getActionName();
      
      // Recupere les parametres de la requete
      // Ceci n'a pas changé ; les méthodes _getParams() et _getParam()
      // relaient simplement l'objet requete maintenant.
      $params = $this->_getParams();
      $foo = $this->_getParam('foo', 'default');
      // parametre de la requete 'foo', en utilisant 'default'
      // en tant que valeur par défaut si aucune valeur n'est trouvée
    • noRouteAction() a été effacée. La manière appropriée de gérer les méthodes d'actions non-existantes est de les router vers une action par défaut en utilisant __call() :

      public function __call($method, $args)
      {
          // Si la méthode requetee ne correspond a aucune methode 'Action',
          // on renvoie vers la méthode d'action par défaut :
          if ('Action' == substr($method, -6)) {
              return $this->defaultAction();
          }
      
          throw new Zend_Controller_Exception('Appel de methode invalide');
      }
  • Zend_Controller_RewriteRouter::setRewriteBase() a été effacée. Utilisez plutôt Zend_Controller_Front::setBaseUrl() (ou Zend_Controller_Request_Http::setBaseUrl(), si vous utilisez cette classe de requête).

  • Zend_Controller_Plugin_Interface a été remplacée par Zend_Controller_Plugin_Abstract. Toutes les méthodes acceptent et retournent maintenant un objet L'objet Requête au lieu d'un élément du distributeur.

Previous Next
Introduction to Zend Framework
Présentation
Installation
Zend_Acl
Introduction
Affiner les Contrôles d'Accès
Utilisation avancée
Zend_Amf
Introduction
Zend_Amf_Server
Zend_Application
Introduction
Zend_Application Quick Start
Théorie générale
Exemples
Fonctionnalités principales
Plugins de ressources disponibles
Zend_Auth
Introduction
Authentification avec une table de base de données
Authentification "Digest"
Adaptateur d'authentification HTTP
LDAP Authentication
Authentification OpenID
Zend_Cache
Introduction
Aspect théorique
Les frontends Zend_Cache
Les backends Zend_Cache
Zend_Captcha
Introduction
Opération Captcha
Adaptateurs CAPTCHA
Zend_CodeGenerator
Introduction
Exemples Zend_CodeGenerator
Zend_CodeGenerator Réference
Zend_Config
Introduction
Aspect théorique
Zend_Config_Ini
Zend_Config_Xml
Zend_Config_Writer
Zend_Config_Writer
Zend_Console_Getopt
Introduction
Déclarer les règles Getopt
Extraire les options et les arguments
Configurer Zend_Console_Getopt
Zend_Controller
Zend_Controller - Démarrage rapide
Fondations de Zend_Controller
Le contrôleur frontal (Front Controller)
L'objet Requête
Routeur Standard
Le distributeur
Contrôleurs d'action
Aides d'action (Helper)
Objet de réponse
Plugins
Utilisation de conventions de dossiers modulaires
Exceptions avec MVC
Migrer depuis des versions précédentes
Zend_Currency
Introduction à Zend_Currency
How to Work with Currencies
Migrer depuis des versions antérieures
Zend_Date
Introduction
Aspect théorique
Méthodes de base
Zend_Date API Overview
Créer des dates
Constants for General Date Functions
Exemples concrets
Zend_Db
Zend_Db_Adapter
Zend_Db_Statement
Zend_Db_Profiler
Zend_Db_Select
Zend_Db_Table
Zend_Db_Table_Row
Zend_Db_Table_Rowset
Relations Zend_Db_Table
Zend_Db_Table_Definition
Zend_Debug
Afficher des informations
Zend_Dojo
Introduction
Zend_Dojo_Data: dojo.data Envelopes
Les aides de vues Dojo
Les éléments de formulaire et les décorateurs Dojo
Zend_Dojo build layer support
Zend_Dom
Introduction
Zend_Dom_Query
Zend_Exception
Utiliser les exceptions
Zend_Feed
Introduction
Importer des flux
Obtenir des flux à partir de pages Web
Consommer un flux RSS
Consommer un flux Atom
Consommer une entrée Atom particulière
Modifier la structure du flux ou des entrées
Classes personnalisées pour les flux et entrées
Zend_Feed_Reader
Zend_File
Zend_File_Transfer
Validateurs pour Zend_File_Transfer
Filtres pour Zend_File_Transfer
Migrer à partir des versions précédentes
Zend_Filter
Introduction
Classes de filtre standards
Chaînes de filtrage
Écriture de filtres
Zend_Filter_Input
Zend_Filter_Inflector
Migrating from Previous Versions
Zend_Form
Zend_Form
Zend_Form démarrage rapide
Creating Form Elements Using Zend_Form_Element
Creating Forms Using Zend_Form
Créer un visuel personnalisé en utilisant Zend_Form_Decorator
Standard Form Elements Shipped With Zend Framework
Décorateurs standards fournis avec Zend Framework
Internationaliser un formulaire Zend_Form
Advanced Zend_Form Usage
Zend_Gdata
Introduction
Authentification par procédé AuthSub
Using the Book Search Data API
Authentification avec ClientLogin
Using Google Calendar
Using Google Documents List Data API
Using Google Health
Using Google Spreadsheets
Using Google Apps Provisioning
Using Google Base
Utilisation des albums Web Picasa
Using the YouTube Data API
Attraper les exceptions Gdata
Zend_Http
Introduction
Zend_Http_Client - Utilisation avancée
Zend_Http_Client - Adaptateurs de connexion
Migrer depuis les versions précédentes
Zend_Http_Cookie and Zend_Http_CookieJar
Zend_Http_Response
Zend_InfoCard
Introduction
Zend_Json
Introduction
Utilisation de base
Utilisation avancée de Zend_Json
XML to JSON conversion
Zend_Json_Server - JSON-RPC server
Zend_Layout
Introduction
Zend_Layout - Démarrage rapide
Zend_Layout options de configuration
Zend_Layout, utilisation avancée
Zend_Ldap
Introduction
API overview
Usage Scenarios
Tools
Object oriented access to the LDAP tree using Zend_Ldap_Node
Getting information from the LDAP server
Serializing LDAP data to and from LDIF
Zend_Loader
Charger les fichiers et les classes dynamiquement
L'autoloader
Autoloaders de ressources
Chargeur de Plugins
Zend_Locale
Introduction
Using Zend_Locale
Normalization and Localization
Working with Dates and Times
Supported locales
Migrer à partir des versions précédentes
Zend_Log
Présentation
Rédacteurs (Writers)
Formateurs (mise en forme)
Filtres
Zend_Mail
Introduction
Envoyer des émail en utilisant SMTP
Envoyer plusieurs émail par connexion SMTP
Utiliser différents transports
Émail HTML
Fichiers joints
Ajouter des destinataires
Contrôler les limites MIME
En-têtes additionnels
Jeux de caractères
Encodage
Authentification SMTP
Sécuriser les transports SMTP
Lire des émail
Zend_Measure
Introduction
Création d'une mesure
Récupérer des mesures
Manipuler des mesures
Types de mesures
Zend_Memory
Présentation
Manager de mémoire
Objet mémoire
Zend_Mime
Zend_Mime
Zend_Mime_Message
Zend_Mime_Part
Zend_Navigation
Introduction
Pages
Containers
Migrating from Previous Versions
Zend_OpenId
Introduction
Zend_OpenId_Consumer Basics
Zend_OpenId_Provider
Zend_Paginator
Introduction
Utilisation
Configuration
Utilisation avancée
Zend_Pdf
Introduction
Créer et charger des documents PDF
Sauvegarder les changement dans un document PDF
Les pages d'un document
Dessiner
Interactive Features
Informations du document et métadonnées
Exemple d'utilisation du module Zend_Pdf
Zend_ProgressBar
Zend_ProgressBar
Zend_Queue
Introduction
Example usage
Framework
Adapters
Customizing Zend_Queue
Stomp
Zend_Reflection
Introduction
Zend_Reflection Exemples
Réference de Zend_Reflection
Zend_Registry
Utiliser le registre
Zend_Rest
Introduction
Zend_Rest_Client
Zend_Rest_Server
Zend_Search_Lucene
Vue d'ensemble
Créer des index
Searching an Index
Query Language
Query Construction API
Jeu de caractères
Extensibility
Agir avec Lucene Java
Avancé
Bonnes pratiques
Zend_Server
Introduction
Zend_Server_Reflection
Zend_Service
Introduction
Zend_Service_Akismet
Zend_Service_Amazon
Zend_Service_Amazon_Ec2
Zend_Service_Amazon_Ec2: Instances
Zend_Service_Amazon_Ec2: Windows Instances
Zend_Service_Amazon_Ec2: Reserved Instances
Zend_Service_Amazon_Ec2: CloudWatch Monitoring
Zend_Service_Amazon_Ec2: Amazon Machine Images (AMI)
Zend_Service_Amazon_Ec2: Elastic Block Stroage (EBS)
Zend_Service_Amazon_Ec2: Elastic IP Addresses
Zend_Service_Amazon_Ec2: Keypairs
Zend_Service_Amazon_Ec2: Regions and Availability Zones
Zend_Service_Amazon_Ec2: Security Groups
Zend_Service_Amazon_S3
Zend_Service_Amazon_Sqs
Zend_Service_Audioscrobbler
Zend_Service_Delicious
Zend_Service_Flickr
Zend_Service_Nirvanix
Zend_Service_ReCaptcha
Zend_Service_Simpy
Introduction
Zend_Service_StrikeIron
Zend_Service_StrikeIron: Bundled Services
Zend_Service_StrikeIron: Advanced Uses
Zend_Service_Technorati
Zend_Service_Twitter
Zend_Service_Yahoo
Zend_Session
Introduction
Usage basique
Utilisation avancée
Gestion générale de la session
Zend_Session_SaveHandler_DbTable
Zend_Soap
Zend_Soap_Server
Zend_Soap_Client
WSDL
Auto découverte
Zend_Tag
Introduction
Zend_Tag_Cloud
Zend_Test
Introduction
Zend_Test_PHPUnit
Zend_Test_PHPUnit_Db
Zend_Text
Zend_Text_Figlet
Zend_Text_Table
Zend_TimeSync
Introduction
Utiliser Zend_TimeSync
Zend_Tool_Framework
Introduction
Using the CLI Tool
Architecture
Creating Providers to use with Zend_Tool_Framework
Shipped System Providers
Extending and Configuring Zend_Tool_Framework
Zend_Tool_Project
Introduction
Create A Project
Zend Tool Project Providers
Zend_Translate
Introduction
Adaptateurs pour Zend_Translate
Utiliser les adaptateurs de traduction
Creating source files
Additional features for translation
Plural notations for Translation
Migrer à partir des versions précédentes
Zend_Uri
Zend_Uri
Zend_Validate
Introduction
Classes de validation standard
Chaînes de validation
Écrire des validateurs
Validation Messages
Zend_Version
Lire la version de Zend Framework
Zend_View
Introduction
Scripts de contrôleur
Scripts de vue
Aides de vue
Zend_View_Abstract
Migration depuis les versions précédentes
Zend_Wildfire
Zend_Wildfire
Zend_XmlRpc
Introduction
Zend_XmlRpc_Client
Zend_XmlRpc_Server
Configuration système requise par Zend Framework
Introduction
Convention de codage PHP de Zend Framework
Vue d'ensemble
Formatage des fichiers PHP
Conventions de nommage
Style de codage
Zend Framework Documentation Standard
Overview
Documentation File Formatting
Recommendations
Recommended Project Structure for Zend Framework MVC Applications
Overview
Recommended Project Directory Structure
Module Structure
Rewrite Configuration Guide
Zend Framework Performance Guide
Introduction
Chargement des classes
Zend_Db Performance
Internationalisation (i18n) and Localisation (l10n)
View Rendering
Informations de copyright