Créer et rendre des éléments compositesDans la dernière section, nous avions un exemple traitant un élément "date de naissance":
Comment représenteriez-vous cet élément en tant que Zend_Form_Element? Comment écrire un décorateur qui s'assure de son rendu ? L'élémentLes questions à se poser sur le fonctionnement de l'élément sont:
Les deux première questions se positionnent sur l'élément de formulaire lui-même, comment vont fonctionner les méthodes setValue() et getValue()? L'autre question nous suggère de nous questionner sur comment récupérer les segments représentant la date, ou comment les affecter dans l'élément? La solution est de surcharger la méthode setValue() dans l'élément pour proposer sa propre logique. Dans le cas de notre exemple, notre élément devrait avoir trois comportements distincts:
En interne, les jour, mois et année seront stockés distinctement. Lorsque la valeur de l'élément sera demandée, nous récupèrerons une chaine formatée et normalisée. Nous surchargerons getValue() pour assembler les segments élémentaires composant la date. Voici à quoi ressemblerait la classe:
Cette classe est fléxible : nous pouvons affecter les valeurs par défaut depuis une base de données et être certains qu'elles seront stockées correctement. Aussi, la valeur peut être affectée depuis un tableau provenant des entrées du formulaire. Enfin, nous avons tous les accesseurs distincts pour chaque segment de la date, un décorateur pourra donc créer l'élément comme il le voudra. Le décorateurToujours en suivant notre exemple, imaginons que nous voulions que notre utilisateur saisissent chaque segment jour, mois, année séparément. Heureusement, PHP permet d'utiliser la notation tableau pour créer des éléments, ainsi nous pourrons capturer ces trois valeurs en une seule et nous crérons un élément Zend_Form traitant avec des valeurs en tableau. Le décorateur est relativement simple: Il va récupérer le jour, le mois et l'année de l'élément et passer chaque valeur à une aide de vue qui rendra chaque champ individuellement. Nous les rassemblerons ensuite dans le rendu final.
Il faut maintenant préciser à notre élément d'utiliser notre décorateur par défaut. Pour ceci, il faut informer l'élément du chemin vers notre décorateur. Nous pouvons effectuer ceci par le constructeur:
Notez que l'on fait cela en constructeur et non dans la méthode init(). Ceci pour deux raisons. D'abord, ceci permet d'étendre dans le futur notre élément afin d'y ajouter de la logique dans init sans se soucier de l'appel à parent::init(). Ensuite, celà permet aussi de redéfinir le décorateur par défaut Date dans le futur si celà devient nécessaire, via le constructeur ou la méthode init. Ensuite, nous devons réécrire la méthode loadDefaultDecorators() pour lui indiquer d'utiliser notre décorateur Date:
A qyuoi ressemble le rendu final ? Considérons l'élément suivant:
Si vous affichez cet élément, vous obtiendrez ce rendu (avec quelques modifications concernant la mise en page du manuel et sa lisibilité):
ConclusionNous avons maintenant un élément qui peut rendre de multiples champs de formulaire, et les traiter comme une seule entité -- la valeur dateOfBirth sera passée comme un tableau à l'élément et celui-ci créra les segments de date appropriés et retournera une valeur normalisée. Aussi, nous pouvons toujours utiliser des décorateurs différents avec l'élément. Si nous avions voulu utiliser un décorateur » Dojo DateTextBox -- qui accepte et retourne des chaines -- we aurions pu, sans modification sur l'élément lui-même. Enfin, vous avez une API uniforme pour décrire un élement se composant se plusieurs segments distincts.
|