La planification de ColdFusion MX 7 a permis à l'équipe ColdFusion de se concentrer sur les balises cfform. Les commentaires des utilisateurs ne permettaient aucun doute : la fonction cfform devait être remaniée pour les formulaires HTML. Nous savions également que nous devions aider les développeurs ColdFusion à profiter de la richesse de Macromedia Flash Player et donner à la balise cfform toute la souplesse des formulaires XForms. Nous savions que si nous pouvions arriver à accomplir tout cela avec une syntaxe de balise cfform simple et élégante, les avantages seraient nombreux.

A l'origine, la prise en charge de la balise cfform par ColdFusion était simplement quelques balises qui produisaient une validation JavaScript de base, validation critiquée par un grand nombre. ColdFusion MX 7 a changé tout cela. Nous avons décidé qu'il était temps de se débarrasser de certains aspects de la création de formulaires et de redonner un nouveau souffle à la balise cfform.

Nous avons d'abord analysé les demandes d'améliorations et les rapports de bogues de la balise cfform. Cela nous a obligé à tout reprendre à zéro, mettre la validation à jour, ajouter de nouvelles balises et corriger « quelques » bogues.

Une fois des bases solides bien établies, nous nous sommes concentrés sur les fonctionnalités de la balise cfform. Cette seconde étape de notre processus de développement a commencé il y a déjà plusieurs années. La fusion entre Allaire et Macromedia avait entraîné de nombreuses discussions sur la possibilité de créer des contenus Flash à partir de ColdFusion, et tout spécialement des formulaires. Au cours du développement de ColdFusion MX 6, il avait été question de l'avantage présenté par l'utilisation de gestionnaires de mise en page avec les formulaires HTML, une méthode similaire à la façon dont les formulaires sont définis dans les applications Swing Java. Ce n'est qu'à partir de ColdFusion MX 7 que nous avons pu consacrer le temps nécessaire pour atteindre cet objectif.

Mise à jour de la balise cfform

Comme pour le développement de tout produit, la première étape consistait à évaluer la fondation. Il nous fallait, avant d'ajouter toutes sortes de nouvelles fonctions aux balises de formulaires, rendre la fondation aussi solide que possible. Le premier cycle de développement a été consacré à la mise à jour des balises cfform. Mais qu'est-ce que cela impliquait ?

Comme vous le savez peut-être, certaines balises ColdFusion ne sont pas rédigées en Java, mais plutôt en CFML pour vos pages CFML, tout comme les balises ColdFusion personnalisées que vous créez. Cependant, la façon dont les balises ColdFusion personnalisées sont associées à leurs parents n'offrait pas la souplesse nécessaire pour atteindre les objectifs que nous avions fixé pour l'ajout de la prise en charge des formulaires XML et Flash aux balises de formulaires. La première étape a donc consisté à réécrire ces balises en Java tout en ajoutant les balises HTML manquantes que les balises cfform ne produisaient pas. Je vous le dirai franchement, j'ai toujours détesté le fait que je pouvais utiliser cfinput pour définir un champ de texte mais pas un bouton d'envoi de formulaire. Un des avantages d'être à la fois un utilisateur et un développeur du produit est que je peux corriger ce que je veux.

Une fois les nouvelles balises remaniées, nous nous sommes attaqués aux bogues. Nous savions que les utilisateurs avaient suggéré de nombreuses améliorations de la balise cfform. Pour ne rien rater, nous avons examiné toutes les demandes d'améliorations et les rapports de bogues depuis ColdFusion 3 et avons transféré les dossiers non clos à la file d'attente de ColdFusion MX 7. Même si nous avons décidé de ne pas corriger tous les bogues ou répondre à toutes les demandes, nous voulions être certains d'avoir évalué tous les dossiers en cours. Cela n'a rien d'exceptionnel ; nous avons procédé de la même façon pour la plupart des fonctions de ColdFusion MX 7, et pas simplement pour les balises cfform.

Page 1 sur 5

Page suivante

A propos de l'auteur