Quelqu'un a-t-il migré de Struts 1 vers un autre framework Web?

Question

Sur mon projet actuel, nous utilisons Struts 1 depuis quelques années et ... heu ... Struts montre son âge. Nous migrons lentement notre code frontal vers un client Ajax qui utilise XML depuis les serveurs. Je me demande si l'un d'entre vous a migré une application Struts existante vers un autre cadre et quels défis vous avez rencontré 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 ayons utilisé JSON plutôt que XML. Il est beaucoup plus facile d'analyser.) Cependant, vous devez être conscient du fait qu'il s'agit en réalité d'une réécriture complète de votre application.

Au lieu du schéma classique Base de données / JSP / Actions pour MVC, vous vous retrouvez en train de passer à un schéma Servlet / Javascript dans lequel le modèle est représenté par des requêtes HTTP GET, les actions étant représentées par des requêtes POST / PUT / DELETE et la vue est rendue à la volée par le navigateur Web. Cela pose des défis intéressants dans chaque domaine:

Côté serveur : côté serveur, vous devrez développer une norme permettant d'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. C’est assez simple à mettre en oeuvre avec des servlets, mais Sun a également développé un schéma Java 1.6. en utilisant des attributs qui ont l'air plutôt cool.

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

JSON est beaucoup plus facile à analyser et plus cohérent dans ses résultats. Javascript et Actionscript (Flash) peuvent tous deux traduire JSON directement en objets. Cela rend l'accès aux données une simple affaire 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 code Javascript. Surtout ceux qui pensent le faire. Si vous avez des livres sur Javascript, jetez-les par la fenêtre MAINTENANT. Il n’existe pratiquement aucun bon livre sur la langue, car ils suivent tous le même "hacking". sans plonger vraiment dans ce qu’ils font.

À partir du niveau le plus bas, votre équipe aura besoin d’une formation de rattrapage sur le développement de Javascript. Commencez par le guide du client Javascript . Il s’agit de la source de facto d’informations sur la langue. La prochaine étape est la les vidéos de Douglas Crockford sur Javascript. Je ne suis pas d'accord avec tout ce qu'il a à dire, mais il est l'un des rares experts en langue.

Une fois que vous avez terminé, déterminez quels cadres vous souhaitez utiliser, le cas échéant. 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 évaluer ces outils et décider s’ils fonctionneront pour vous.

Si vous pensez absolument que vous ne pouvez pas vivre sans framework car 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 perdez énormément de flexibilité en procédant ainsi. Le langage Javascript est beaucoup plus puissant que ce que GWT expose. Cependant, GWT permet aux développeurs Java de devenir plus rapides. Alors, choisissez vos batailles.

Ce sont les domaines clés auxquels je peux penser. Je peux dire que vous pousserez un soupir de soulagement une fois que votre candidature aura été renforcée. Cela 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?

Modifier 1: J'ai oublié d'ajouter que votre équipe devait étudier les spécifications du W3C religieusement. Ce sont les API disponibles dans les navigateurs modernes. Si vous attrapez quelqu'un qui utilise les API DOM 0 (par exemple, document.forms ['myform']. Blah.value au lieu de document.getElementById ("blah"). Valeur), forcez-les à transcrire l'intégralité de la spécification DOM 1 jusqu'à ce qu'ils le comprennent de haut en bas.

Éditer 2: Un autre problème clé à prendre en compte est de savoir comment documenter votre nouvelle application AJAX. Les interfaces de style REST se prêtent bien à être documentées dans un wiki. Ce que j'ai fait était d'avoir une page de haut niveau répertoriant chacun des services et une description. En cliquant sur le chemin de service, vous accédez à un document contenant des informations détaillées sur chacun des sous-chemins. En théorie, ce schéma peut documenter aussi profondément que vous avez besoin de l'arborescence.

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 sous forme de documentation. Cela fonctionne bien pour les arbres d'objet simples, mais peut devenir complexe avec des objets plus volumineux et plus sophistiqués. Vous pouvez envisager de compléter par quelque chose comme IDL ou WebIDL dans ce cas. (Ne peut pas être pire que les DTD et les schémas XML.; -))

Le code DHTML est un peu plus classique dans sa documentation. Vous pouvez utiliser un outil tel que 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 à la documentation en code. Si pour aucune autre raison que le fait que cela gonfle le téléchargement. Cependant, vous pouvez vous retrouver régulièrement en train d’écrire du code qui fonctionne comme un objet cohérent, mais n’est pas codé en coulisse comme un tel objet. La meilleure solution consiste donc à créer des fichiers squelettes JSDoc qui représentent et documentent les objets Javascript.

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

Answer 2

Découvrez le Framework Stripes . Si vous connaissez bien les jambes de force, les rayures auront un 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. Cela vous permet de travailler avec n'importe quel framework ajax que vous voulez, et je ne pense pas qu'il faudrait beaucoup de temps pour migrer de struts en stripes.