Est-ce que quelqu'un a migré de Struts 1 vers un autre framework Web?

Question

Sur mon projet actuel, nous utilisons Struts 1 depuis quelques années, et ... hum ... Struts montre son âge. Nous migrons lentement notre code frontal vers un client Ajax qui consomme du XML à partir des serveurs. Je me demande si certains d'entre vous ont migré une application Struts héritée vers un cadre différent, et quels défis vous avez rencontrés pour le faire.

Answer 1

Bien sûr. Passer de Struts à un framework AJAX est une expérience très libératrice. (Bien que nous utilisions JSON plutôt que XML, il est beaucoup plus facile à analyser.) Cependant, vous devez savoir qu'il s'agit en fait d'une réécriture complète de votre application. Au lieu du schéma classique Database/JSP/Actions pour MVC, vous vous trouvez dans un schéma Servlet/Javascript où le modèle est représenté par des requêtes HTTP GET, les actions sont représentées par des requêtes POST/PUT/DELETE, et la vue est rendue à la volée par le navigateur Web. Cela entraîne des défis intéressants dans chaque domaine:

Côté serveur - Du côté serveur, vous devrez développer une norme pour exposer les données au client. La méthode la plus simple et la plus simple consiste à adopter une méthodologie REST qui correspond le mieux à la hiérarchie de vos données. Ceci est assez simple à mettre en œuvre avec les servlets, mais Sun a également développé un Java 1.6 scheme en utilisant des attributs qui ont l'air plutôt cool.

Un autre aspect du côté serveur consiste à choisir un protocole de transmission. Je sais que vous avez déjà mentionné XML, mais vous pourriez vouloir reconsidérer. Les analyseurs XML varient considérablement entre les navigateurs. Un navigateur peut faire en sorte que le document racine le premier enfant, un autre peut ajouter un objet de contenu spécial, et ils analysent tous les espaces différemment. Pire encore, la fonction normalize() ne semble pas être correctement implémentée par les principaux navigateurs. Ce qui signifie que l'analyse XML est susceptible d'être pleine de hacks.

JSON est beaucoup plus facile à analyser et plus cohérente dans ses résultats. Javascript et Actionscript (Flash) peuvent traduire JSON directement en objets. Cela rend l'accès aux données une simple question de x.y ou x [y]. Il existe également de nombreuses API pour gérer JSON dans toutes les langues imaginables. Parce qu'il est si facile à analyser, il est presque mieux pris en charge que XML!

Côté client - Le premier problème que vous allez rencontrer est le fait que personne ne comprend comment écrire du Javascript. Surtout ceux qui pensent qu'ils le font. Si vous avez des livres sur Javascript, jetez-les par la fenêtre MAINTENANT. Il n'y a pratiquement pas de bons livres sur la langue car ils suivent tous le même modèle de "piratage" sans vraiment plonger dans ce qu'ils font. Au niveau le plus bas, votre équipe aura besoin d'une formation corrective sur le développement Javascript. Commencez par le Javascript Client Guide. C'est la source d'information de facto sur la langue. L'arrêt suivant est Douglas Crockford's videos sur Javascript. Je ne suis pas d'accord avec tout ce qu'il a à dire, mais il est l'un des rares experts en la matière.

Une fois que vous l'aurez compris, considérez les frameworks, le cas échéant, que vous souhaitez utiliser. De manière générale, je n'aime pas les choses comme Prototype et Mootools. Ils ont tendance à prendre un problème simple et à l'aggraver. Néanmoins, vous pouvez vous sentir libre d'évaluer ces outils et de décider s'ils fonctionneront pour vous.

Si vous pensez absolument que vous ne pouvez pas vivre sans cadre parce que votre équipe est trop inexpérimentée, alors GWT pourrait faire l'affaire. GWT vous permet d'écrire rapidement des applications web DHTML en code Java, puis de les compiler en Javascript. Le PROBLÈME est que vous abandonnez une grande quantité de flexibilité en faisant cela. Le langage Javascript est beaucoup plus puissant que GWT.Cependant, GWT permet aux développeurs Java de se mettre à jour plus rapidement. Alors choisissez vos batailles.

Ce sont les domaines clés que je peux penser. Je peux dire que vous allez pousser un soupir de soulagement une fois que vous obtenez des struts de votre application. Ça peut être un peu une bête. Surtout si vous avez eu des développeurs inexpérimentés travaillant sur votre modèle Struts. :-)

Des questions? J'ai oublié d'ajouter que votre équipe devrait étudier le W3C specs religieusement. Ce sont les API disponibles dans les navigateurs modernes. Si vous attrapez quelqu'un utilisant les API DOM 0 (par exemple document.forms ['myform'] .blah.value au lieu de document.getElementById ("blah"). Value) les force à transcrire la totalité de la spécification DOM 1 jusqu'à ce qu'ils la comprennent top au fond.

Édition 2: Une autre question clé à considérer est de savoir comment documenter votre nouvelle application AJAX de fantaisie. Les interfaces de style REST se prêtent bien à être documentées dans un Wiki. Ce que j'ai fait était une page de haut niveau qui énumérait chacun des services et une description. En cliquant sur le chemin de service, vous serez dirigé vers un document avec des informations détaillées sur chacun des sous-chemins. En théorie, ce schéma peut documenter aussi loin que vous avez besoin de l'arbre à parcourir.

Si vous utilisez JSON, vous devrez développer un schéma pour documenter les objets. Je viens d'énumérer les propriétés possibles dans le wiki en tant que documentation. Cela fonctionne bien pour les arbres d'objets simples, mais peut devenir complexe avec des objets plus grands et plus sophistiqués. Vous pouvez envisager de compléter avec quelque chose comme IDL ou WebIDL dans ce cas. (Ne peut pas être bien pire que les DTD et schémas XML. ;-))

Le code DHTML est un peu plus classique dans sa documentation. Vous pouvez utiliser un outil comme JSDoc pour créer une documentation de style JavaDoc. Il y a juste une mise en garde. Le code Javascript ne se prête pas bien à être documenté en code. Si pour aucune autre raison que le fait qu'il gonfle le téléchargement. Cependant, vous pouvez vous trouver régulièrement en train d'écrire du code qui fonctionne comme un objet cohérent, mais qui n'est pas codé derrière les scènes en tant qu'objet. La meilleure solution est donc de créer des fichiers squelette JSDoc qui représentent et documentent les objets Javascript.

Si vous utilisez GWT, la documentation devrait être une évidence.

Answer 2

Consultez le Stripes Framework. Si vous connaissez les entretoises, les rayures auront du sens pour vous, mais c'est tellement mieux. Ils ont une section Stripes vs Struts sur leur site Web. Vous pouvez vérifier cela et voir si cela vous intéresse. Il vous permet de travailler avec n'importe quel framework ajax, et je ne pense pas que cela prendrait du temps pour migrer des struts vers les stripes.