Consultez la FAQ sur le ZF avant de poster une question
Vous n'êtes pas identifié.
Salut tout le monde,
Ca fait un moment que je bosse avec le framework zend et d'habitude j'arrive à m'en sortir sans trop de mal.
Là, je bloque sur ce qui est peut être une limite dans les "multi" du zend_form : à ma connaissance, on ne peut pas donner d'attribut supplémentaire aux "option" des zend_form_element_multi*.
Dans mon projet actuel j'ai besoin de ça pour deux raisons :
1) afficher des infos bulles sans javascript (je sais, des infos bulles sur un "<option>", c'est le mal )
2) fournir des données à une fonction javascript
Je poste sur ce forum par ce que je ne vois pas ce qui serait la meilleure solution face à mon problème. La plus simple et propre que je vois c'est d'étendre la classe zend_form_element_multi et créer les enfants dont j'ai besoin (bref reproduire une partie de l'arbo zend/Form) et remplacer le decorator qui correspond aux "<option>".
Si l'un de vous à une meilleure idée, je le remercie par avance.
Hors ligne
On ne peut pas ajouter d'autres attributs à la balise option depuis un Zend_Form actuellement. Il faudrait étendre l'aide de vue, et l'élément également. Il faudrait un tableau à plusieurs niveaux pour pouvoir stocker plusieurs informations pour une option.
Tu as une deuxième approche, tu peux stocker les données pour ta fonction javascript dans un json par exemple. La valeur de l'option serait utilisée comme clef. Tu sépares mieux d'un point de vue sémantique, et cela évite d'étendre des classes.
Hors ligne
Salut,
Je te remercie pour ta réponse.
J'avais pensé à la seconde solution que tu proposes mais je l'ai rejeté pour plusieurs raisons :
- il est impossible de faire des infos bulles sans javascript si on a besoin de javascript pour récupérer les données à afficher dans l'info bulle
- utiliser du json pour ça veut dire multiplier les requêtes http et si la liste dépend du résultat d'une requête, ça veut dire refaire la requête ou stocker les données dans un cache (session ou autre)
- d'un point de vue sémantique, des "data-*" (données liés à un éléments de la page mais qui ne servent que pour les langages côtés navigateurs) de l'html5 me semblent aussi bon qu'une fonction qui sert à récupérer les paramètres secondaires des "option"
- si on récupère les données en javascript alors il faut que la fonction javascript arrive à faire la liaison entre l'élément du formulaire et les données que le serveur lui envoie. Ca veut dire soit rajouter des infos dans le "select", soit normaliser les noms de manière très stricte pour être sur que ça soit unique au niveau du site. Normaliser les noms à ce point me parait lourd et si on part sur le rajout de données, autant que ça soit directement dans les options et sans javascript.
S'il n'y a que ces deux possibilités là alors je vais partir dans l'extension de classes vu que de toute manière je tiens à mes infos bulles sans javascript.
Dernière modification par omega2 (13-07-2010 18:23:38)
Hors ligne