Surveiller ce forum | 
Commencer une nouvelle discussion
| RE: Rex - Struts2 [ Répondre ] Par : Benjamin Leperchey on 2008-01-04 17:23 | [forum:53089] |
|
j'ai des doutes sur l'AJAX selon Struts. Ca reste comme souvent (Ruby on Rails & co) juste des tags pour coller des fragments de HTML ici et là. On est encore loin de l'utilisation du XML comme en ACube. Sauf erreur de ma part, les thèmes ne s'appliquent d'ailleurs qu'aux JSP, qui ne sont pas utilisées en ACube (puisque les pages HTML sont statiques) Ce qui se rapproche le plus de la méthodologie ACube dans ce que j'ai vu sur la page Struts 2, c'est l'intégration avec Dojo, mais dans ce cas, la seule plus-value des thèmes, c'est le formatage et le décodage du JSON : tout le Javascript client des exemples est écrit comme en ACube (à part, bien sûr, que c'est du Dojo) |
|
| RE: Rex - Struts2 [ Répondre ] Par : Benjamin Leperchey on 2008-01-04 17:17 | [forum:53088] |
|
Effectivement, c'est plus agréable que Struts 1. J'aime beaucoup : - les paramètres mis dans les champs de l'action. c'est plus lisible que des ActionForms séparés, et plus pratique que des GetRequest.getXXX comme on en faisait jusqu'ici. - les propriétés au niveau du package. - l'intégration du validator avec le client ACube (utilisation de la feuille de style pour afficher les erreurs dans une popup) J'aime bien, mais un peu moins : - le mapping URL->java par annotation de la classe. C'est pratique, mais comme chaque mapping est indépendant des autres, on risque d'avoir un problème pour cartographier l'application (avec CAST par exemple). le mieux serait à mon avis d'exploiter à fond la convention, en définissant un modèle de mapping dans struts-config.xml (ce que semble savoir faire struts 2) Mais, comme pour Struts 1, on utilise 10% du produit : struts est quand même plus fait pour gérer la navigation entre les pages que pour faire des actions de type "service web REST". On n'utilise que le mapping url->action et le validator... Par contre, il manque toujours l'injection de dépendances, ce qui oblige à faire des factories (DAO, entre autres) et à multiplier les fichiers de configuration, chacun avec sa syntaxe. Ca serait intéressant de regarder ce que ça pourrait donner d'ajouterGuice ou le conteneur Spring à Struts 2. Et il faudrait quand même, à mon avis, regarder à quoi pourrait ressembler une appli ACube "full Spring". |
|
| RE: Rex - Struts2 [ Répondre ] Par : Kadvaël COIFFET on 2007-12-04 18:31 | [forum:53024] |
| J'ai mis dans les Developpers Feature Requests ACube-LISE-J2EE une application démo de struts 2. | |
| RE: Rex - Struts2 [ Répondre ] Par : Cyril Rocheteau on 2007-12-04 10:33 | [forum:53020] |
|
je rejoint Kadvaël sur l'interêt de Struts2 par rapport à Struts en géneral et dans le contexte Acube. Plus simple, plus productif que la v1. La migration de la v1 à la v2 est assez simple si on n'utilisait pas les fonctions avancées de Struts V1 (tiles, validator ...). Struts V2 incorpore également une notion de thème & template (simple, xhtml, css+xhtml, ajax). Un theme A3 pour Struts2 serait une manière de packager efficacement l'intégration de FRED. |
|
| Rex - Struts2 [ Répondre ] Par : Kadvaël COIFFET on 2007-12-03 13:36 | [forum:53018] |
|
Voici un petit retour d'expérience sur la version 2 de Struts. Je pense que ce framework est particulièrement adapté à l'environnement Acube. Struts 2 est principalement issu de webWorks2. Voici quelque évolutions intéressantes pour le framework Acube : - Les formulaires sont fusionnés avec les actions en POJO : - Plus besoin de récupérer les paramètres en requête, ni de les formater dans le type souhaité (Pour les dates et les nombres en particuliers) - Facilite les tests puisque plus besoin de requête pour passer les paramètres (Possibilité d'utilisé JUnit) - Moins de configuration : - Possibilité d'utiliser des annotations (pour la correspondance url => actions, pour les conversions de types, pour les types de result, ...) - Utilisation de convention (pour le nom des actions, des fichiers de validation) - Plusieurs types de result pour les actions : - De base il existe un result de type transformation XSLT (Pour remplacer StrutsCX) - Architecture basée sur des plugins : - Il y a plusieurs points d'extension possibles pour les plugins - Les plugins embarquent leur propre configuration (intéressant pour les éléments de configuration du framework qui pourrait être inclus dans les jars du framework et non plus dans le gabarit) - Possibilité par les plugins de créer des actions (Pour l'export Excel et autres fonctionnalités du framework utilisant des actions serveur) - Possibilité par les plugins de créer des types de result par exemple pour StrutsCx (En faite il existe déjà un plugin de transformation XSLT intégré à Struts2) - Possibilité d'ajouter des interceptors sur les actions qui peuvent inclure différents traitements suivant les types d'actions. (Pour les timers, log) - Internationalisation est gérer de base avec différents niveaux (Possibilité d'avoir des fichiers de configuration global, au niveau des packages ,...) - Possibilité de faire de la validation par fichier XML pour chaque action (un interceptor spécifique Acube pourrait traité les cas d'erreur) En conclusion Struts 2 est plus simple de par l'utilisation de convention et d'annotation et plus souple que struts 1 avec la possibilité de personnaliser la configuration par package, par action, etc... Il fait plus de chose (types de result différents, ...) et peut être plus facilement enrichi et personnalisé avec l'utilisation de plugins. Des tests automatisés peuvent être réalisés plus facilement (utilisation POJO Actions). Le remplacement de strutsCX est assuré de base dans struts 2 qui gère l'internationalisation. |
|
