Stripes contre Struts

Stripes est né de ma frustration continuelle due au manque d'un framework web de haute qualité et facile à utiliser. Bien sûr, Struts a des qualités, mais il y a beaucoup de petits détails qui deviennent encombrants. Beaucoup de petites choses qu'on apprend à detourner, et à vivre avec, sans réaliser que cela ne nous rend pas productifs.

Jusqu'à récemment cela aurait été très difficile de créer un framework qui soit assez bon pour rivaliser avec Struts. Et, avec JSF toujours à l'horizon (perpétuellement?), et d'autres frameworks dans la même sphère (WebWork, Tapestry, Wicket) il y en a qui doutent du raisonnement sous-jacent à la création d'encore un autre framework. Mais avec Java v1.5 et Servlet v2.4 je crois que c'est maintenant où jamais. Le raisonnement est très simple - je voulais un framework web qui rend l'écriture des applications web facile, même plutôt amusante, en Java.

Nombre d'Objets Périphériques

Une de mes plus grandes frustrations à propros de Struts est que pour implémenter une seule page ou form, il faut que j'écrive ou édite de nombreux fichiers. Et il faut les syncroniser tous ou ça rate vraiment. Avec Struts il faut que j'écrive mon JSP, mon Action, mon Form, une entrée dans le fichier struts-config.xml pour form-bean, une autre entrée pour l'action, et si je fais tout selon Struts, beaucoup de forwards dans le fichier struts-config.xml aussi. Ne parlons pas du fait que tout ça est sauvegardé dans un fichier XML et que dans une équipe nous nous trouvons confrontés aux conflits de fusion. Oui, il y a des annotations pour Struts, mais elles correspondent à ce qu'il y avait dans le fichier XML, et elles ne m'ont pas l'air vraiment correctes.

Comparons tout ça avec Stripes. J'écris mon JSP. J'écris mon ActionBean et je l'annote avec @UrlBinding pour spécifier l'URL auquel il devrait répondre, et une ou plusieurs @HandlesEvent annotations pour lier les événements aux fonctions. C'est tout, voila! Toute l'information à propros du form et de l'action est au même endroit.

Développement Cumulatif

Écrivez un JSP avec un tag Struts de <html:form> et essayez de le visualiser dans votre containeur avant d'avoir écrit le form-bean. Boum! Pas possible! Exception! Ne pouvais pas trouver le form-bean. Attendez - ce n'est toujours pas assez. Vu que tout est connecté par le lien de l'action dans le XML vous auriez dû une avoir action, et l'éditer aussi.

Peut-être ce n'est que moi, mais j'aime pouvoir écrire mon JSP, voir s'il a l'air bien, puis aller écrire les objets finaux qui vont avec. Ce n'est pas trop compliqué, et Stripes vous le permet.

Assigner des Propriétés

Struts vous permet d'utiliser des propriétés imbriquées, et c'est bien. Mais si on dit qu'on a une propriété dans le form 'person.address.line1'. Struts essaiera de l'assigner pour vous, mais si l'objet person ou address est null, alors vous serez dégoûtés. Donc, il faut pré-instancier les objets sur lesquels vous voulez utiliser les propriétés imbriquées. Cela nécessite vraiment trop de travail!

Stripes instantiera tout et n'importe quoi pour vous. À partir du moment où 'person' et 'address' ont des constructeurs sans argument Stripes les instantiera, les liera, les assignera sur l'ActionBean et puis assignera la propriété 'line1'. Stripes instantiera même les implémentations pour n'importe quelles interfaces Collections, ce qui m'amène à...

Propriétés Indexées

La spécification JavaBean est bien pour la majeure partie, mais elle provient clairement du côté GUI de Java. L'implémentation de Struts pour des propriétés indexées s'accorde avec la spécification JavaBean, mais dans un modèle web decousu, votre action ne saura pas (et ne devrait pas avoir à savoir) combien de propriétés indexées vont revenir. Pour que ceci marche, nous finissons par coder des fonctions getXxx/setXxx intelligentes qui étendent des listes et insèrent des objet juste pour faire en sorte que Struts ne pose pas de problèmes.

Stripes fait tout à votre place. Vous fournissez un getXxx et un setXxx qui utilisent un List ou un Map, utilisant Generics pour informer Stripes du genre d'objet qui devrait être mis dans le List ou Map. Stripes instanciera le List ou Map pour vous (si c'est necessaire), l'étendra quand il y aura besoin, et instanciera des objets pour les mettre dans le List ou Map et assignera les propriétés des objets qui sont maintenant dans le List ou Map.

Validation

D'autres frameworks critiquent Struts sur sa Validation, c'est juste car celle ci est vraiment au mauvais endroit. Oublions que le Struts Validator requiert encore un autre fichier XML avec plus d'informations sur le Form qu'il faut syncroniser. La Validation de Struts est séparée de la Conversion Type, ce qui est tout simplement faux. Pourquoi valider quelque chose de bien formé, puis passer beaucoup de temps à la convertir? Eh bien, Struts le fait presque. Il consacre beaucoup d'efforts à la validant, la jette, puis il performe une conversion de type médiocre. Ce n'est pas efficace, et c'est agacant à utiliser. C'est pourquoi la plupart des projets Struts que j'ai vu, ne veulent même pas toucher au Struts Validator.

La Validation dans Stripes est liée à la conversion type. Un nombre de validations souvent utilisées peuvent être appliquées avant la conversion type en utilisant une annotation simple. Cela inclus des chose comme - des champs requis, des longueurs de champs, des champs d'expressions régulières etc. Puis la conversion type se fait ou elle essaie du moins. Si elle échoue, les converteurs types produisent des erreurs de validation qui peuvent être montrées à l'utilisateur. Donc, vous pouvez passer du temps à créer des bons converteurs types (s'il ne sont pas déjà inclus pour vos besoins) est c'est tout.

Null signifie Null (ou est-ce le cas)

Demandez-vous ceci. Il y a une propriété int sur un form-bean et l'utilisateur ne rentre rien. Quelle valeur devrait-on assigner à la propriété? Zéro a l'air d'un valeur par défaut raisonnable, non? Maintenant, Que faites vous s'il y a une propriété Integer? Si l'utilisateur ne soumet rien je dirais que cela signifie null pas vous? Apparament Struts pense que cela signifie zéro encore. Et si il y a des erreurs, le formulaire repeuplera avec la valeur zéro! La seule façon pour contourner ceci est de declarer toutes vos propriétés en tant que {{String}}s et de faire votre propre conversion (ce qui représente beaucoup d'efforts si vous vous occuper de plusieurs locaux).

Stripes sait que la spécification HTML est un peu incohérente, et fait ce qu'il peut pour faciliter la situation et rendre les choses cohérentes pour les développeurs d'application. Ce qui fait que, un string vide dans les paramètres de requête est traité comme un champs non envoyé. L'utilisateur n'avait pas rempli le champs, alors pourquoi votre ActionBean devrait-il recevoir quelque chose et comprendre ce que ça veut dire?

Formatage

Le Struts FAQ dit ce qui suit (et plus) en réponse à la question : pourquoi les tags Struts fournissent-ils si peu de formatage.

Des Actions Avec Plusieurs d'Événements

à suivre...

JSP / Aides de Vues

à suivre...

Tags "HTML"

à suivre...