Vous choisissez un framework Web Java maintenant? [fermé]

nous sommes dans la phase de planification de la migration d'un grand site Web qui est construit sur un framework mvc développé sur mesure vers un framework Web basé sur java qui fournit un support intégré pour ajax, contenu rich media, mashup, mise en page basée sur des modèles, validation, html maximum / séparation de code java. Grails semblait être un bon choix, cependant, nous ne voulons pas utiliser de langage de script. Nous voulons continuer à utiliser java. La mise en page basée sur des modèles est une préoccupation majeure car nous avons l'intention d'utiliser cette application Web avec plusieurs sites Web avec des fonctionnalités similaires mais une apparence et une sensation radicalement différentes.

La solution basée sur le portail convient-elle bien à ce problème?

Toutes les informations sur l'utilisation de "Spring Roo" ou "Play" seront très utiles.

J'ai trouvé des articles similaires comme celui-ci , mais ils datent de plus d'un an. Les choses ont sûrement changé entre-temps!

EDIT 1: Merci pour les bonnes réponses! Ce site est en train de devenir la meilleure source d'informations sur les programmeurs dans les tranchées. Cependant, je m'attendais à plus d'informations sur l'utilisation d'un duo portail-cms. Jahia a l'air bien. Quelque chose de similaire?

La solution basée sur le portail convient-elle bien à ce problème?

Personnellement, je resterais à l'écart des grosses solutions Portal (elles sont souvent des tueurs de productivité). J'ai entendu de bonnes choses sur Gatein mais je n'ai aucune expérience réelle avec.

Toutes les informations sur l'utilisation de "Spring Roo" ou "Play" seront très utiles.

À propos de Spring Roo, j'ai lu des réponses précédentes comme Spring roo Vs (Wicket et Spring) et d'autres choses sur Internet mais je ne suis toujours pas convaincu (peut-être que je ne comprends pas), je ne suis pas sûr de sa maturité , et, plus important encore, je me demande vraiment ce que SpringSource fait avec Grails et Roo (non, Grails vs Roo - pourquoi SpringSource pousse deux technologies très similaires? ne me convainc pas qu'ils survivront tous les deux).

Je ne peux pas en dire beaucoup sur Play. J'ai vu la démo comme tout le monde mais j'aimerais lire des commentaires réels. Jusque-là, j'attendrai.

J'ai trouvé des articles similaires (...). Les choses ont sûrement changé entre-temps!

Oui et non :) Mais entrons dans l'enfer des cadres de présentation: il n'y a pas de réponse unique à votre question (comme il y a un an), il y a des dizaines de cadres là-bas et pas de gagnant clair. Pour n'en citer que quelques-uns:

• JSF: Beaucoup de sceptiques sur ce framework basé sur des composants, y compris moi, donc je ne suis pas le meilleur pour en parler mais ...
• JSF 2 (+ CDI / Weld): Les sceptiques de JSF sont encouragés ( par Gavin King ) à «jeter un second regard». En effet, je pense que JSF 2 est une grosse amélioration, surtout avec CDI, mais ... c'est quand même assez récent (comprenez, il manque de retour). Si vous souhaitez adopter Java EE 6, jetez-y un œil.
• Wicket: Un autre cadre basé sur des composants qui attire de plus en plus l'attention. J'entends surtout de bonnes choses à ce sujet: plus simple que JSF, beau design, haute testabilité, convivialité pour les concepteurs HTML, etc.
• Tapisserie: ne le faites pas (voir Pourquoi avez-vous arrêté d'utiliser Tapestry? )
• Struts 2, Spring MVC, Stripes: frameworks basés sur l'action. Tout est correct et couvrira vos besoins (personnellement, j'aime Stripes et sa convention sur l'approche de configuration, voir Stripes vs Struts2 pour en avoir une idée).
• GWT, Flex, Grails: Ce ne sont peut-être pas ce que vous recherchez. Je ne peux pas vraiment parler (des versions récentes) de Flex et GWT mais je sais que Grails a quelques fans .

En fait, je suggérerais de jeter un œil aux présentations de Matt Raible , il a vraiment fait un excellent travail en comparant les cadres Web, en montrant leurs forces et leurs faiblesses, en rassemblant des faits et des chiffres, en montrant les tendances ... Je recommande:

• Comparaison de JSF, Spring MVC, Stripes, Struts 2, Tapestry et Wicket (toujours pas obsolète)
• Cadres Web du futur: Flex, GWT, Rails et Grails (juste pour avoir un avant-goût des alternatives)
• Comparaison des frameworks Web Kick-Ass (celui-ci est le plus récent)

Vraiment, jetez un œil à ces présentations, elles vous aideront à trouver un cadre approprié (il n'y a pas de réponse unique mais vous pouvez restreindre le choix par élimination) et pourraient changer votre point de vue.

J'utilise Spring 3 et Jquery depuis un moment, mais j'ai entendu parler de Play et je l'ai essayé. J'aime vraiment ça, Play est un excellent choix entre quelque chose comme PHP et les frameworks Java robustes comme Spring.

Les choses que j'aime le plus dans le jeu sont:

• Très facile à faire décoller une application de jeu, vous devez aller assez loin avec le codage et la configuration pour obtenir une simple application crud à l'écran avec Spring (bien que Spring 3 ait rendu les choses beaucoup plus faciles).
• Spring Security est génial mais cela se fait au prix de la complexité. Le module de sécurité de Play est très très simple et couvre les besoins de probablement 90% des applications.
• Vous pouvez modifier le code et appuyer sur Actualiser dans le navigateur pour voir le changement comme avec PHP au lieu d'avoir à faire tout le redéploiement avec des frameworks basés sur Servlet.
• Les messages d'erreur sont affichés bien et pas si énigmatiques la plupart du temps. Play doit encore travailler sur leur gestion des erreurs
• Il existe un mécanisme de plugin pour Play qui est assez simple.
• La persistance des objets est très bien faite dans la mesure où une base de données en mémoire et JPA sont fournis avec le framework, il n'y a donc pas de configuration d'outils de persistance d'objets externes. Passer de la base de données en mémoire à un SGBDR réel est un changement d'une ligne dans le fichier de configuration.
• La configuration MVC est très bien faite. La classe Model que vous étendez pour créer vos objets de domaine s'intègre au gestionnaire d'entités JPA. Ce ne sont pas que des POJO.
• Le mappage d'URL aux contrôleurs est simple et flexible et le tout dans un seul fichier «routes».
• Chaque fois que vous créez un projet, Play gère toutes les dépendances jar et Play a un utilitaire pour éclipser (ou n'importe quel IDE que vous aimez) le projet afin qu'il importe directement dans votre IDE préféré.

Ce que je n'aime pas dans Play

• La documentation n'est pas encore entièrement là, de nombreuses fonctionnalités non documentées existent toujours.
• Le framework est le serveur, vous devez donc dédier un port à chaque application. Je pense que quelqu'un travaille sur un plugin d'hôte virtuel mais je ne l'ai pas encore vu en action.
• C'est jeune, le projet est génial et la technologie est géniale, mais il faut vraiment plus de développeurs. J'adorerais y consacrer du temps, on verra.

Le meilleur choix pour moi est Wicket . Séparation claire du balisage et du code java. Composants très faciles à écrire et à utiliser. Simple à utiliser Ajax, testabilité. Vous pouvez déboguer directement dans vos pages / composants et ne pas recevoir de messages d'erreur cryptiques de votre implémentation JSF;)

Il y a aussi un bon guichet de comparaison <--> JSF en termes de performances

Les trois premiers choix pour moi sont (par ordre alphabétique):

• JSF
• Spring MVC
• Jambes 2

Ils:

• avoir un bon support ajax
• vous permettent de créer des sites Web réels, pas des applications (comme GWT)
• stable, bien documenté, largement utilisé
• MVC
• Java pur
• intégration facile avec Spring comme middleware

Le jeu est très similaire à ROR, une version ROR en java

Contrairement à d'autres réponses, je voudrais souligner les inconvénients (IMHO) des frameworks Web populaires:

JSF2 - Sorti et déjà vieilli. Encore quelques nouvelles / articles / articles de blog / expériences. Je suis sceptique. Toujours en attente de la prochaine version majeure de Richfaces / Icefaces qui prend entièrement en charge jsf 2 - actuellement, seules les versions alpha peuvent être téléchargées.

Struts 2 - Cela semble être une bonne chose seulement si vous comptez toujours sur des struts et que vous souhaitez refactoriser la plupart de votre code. Sinon: ne le faites pas.

GWT - Je n'aime pas l'approche mono-page et java-> javascript. Je ne sais pas si une session - plusieurs vues / fenêtres peuvent être facilement réalisées. Pour moi, ce cadre devrait être utilisé pour les applications Internet riches à guichet unique pour utilisateurs massifs.

Wicket - Belle approche, mais un peu verbeux et trop peu de documentation disponible (sauf le bon wicket in action book, mais cela ne couvre que 1.3). Aussi, pour moi, il manque de grands projets qui sont construits dessus. Et je ne vois actuellement pas où va la route du guichet ou si elle a déjà été conduite dans une impasse.

Spring MVC - Je n'ai pas encore essayé cela, mais vous devez inclure de nombreux jars (spring mess) dans votre chemin de classe pour fonctionner correctement avec ce framework. Et il repose sur JSP (dans la plupart des projets), que je considère déjà mort. Et vous n'obtenez qu'un framework MVC pur - toutes les autres choses (ajax et autres) doivent être implémentées / intégrées.

Stripes - Un petit et joli cadre MVC conçu, mais trop moins de documentation, trop moins de commits / committers, trop peu de versions, trop moins de support de l'industrie, trop moins d'activité de liste de diffusion.

Je suis également curieux de savoir si j'ai raté un cadre majeur (j'ai laissé Tapestry intentionnellement) qui pourrait être une option pour vous (et aussi pour moi aussi).

J'ai eu beaucoup de succès avec JAX-RS . C'est le seul Java Web Framework qui possède une sorte de spécification JSR et plusieurs implémentations autres que la spécification de servlet et de portlet (bien que cela puisse être une mauvaise chose).

Une chose qui est mauvaise et bonne à propos de Java est que vous pouvez choisir et faire correspondre les frameworks (python a également cette fonctionnalité / problème). C'est bien parce que vous n'avez pas à mettre tous vos œufs dans le même panier.

Voici une recette générale de pile d'application Web Java:

Javascript / Flash + Traitement des requêtes / réponses + Injection de dépendances + Persistance

Javascript: JQuery, Prototype, Dojo

Demande / Réponse: Spring MVC, Stripes et mon JAX-RS préféré (Jersey, Apache CXF)

Injection de dépendance: Spring, Guice

Persistance: JPA (Hibernate, stockage Google App), Hibernate, JDO et plus.

J'ai également eu beaucoup de succès en utilisant AspectJ pour rendre Java "suck less". En utilisant les mixins ITD de Spring @Configurable et AspectJ, vous pouvez obtenir des Rails comme des objets Domain (c'est en fait ce que fait Roo mais vous n'avez pas besoin de Roo pour le faire).

J'ai trouvé que les rayures étaient vraiment efficaces et étonnamment légères ... elles visent à être plus légères que les jambes de force . J'ai entendu des amis qui sont des développeurs Web à plein temps que JSF ne vaut pas la peine d'être dérangé, même si je n'ai aucune expérience de première main et que je ne peux pas le confirmer avec des exemples (!).

Jetez un œil à RESThub , qui suit les mêmes principes que Play! mais implémenté en réutilisant certains frameworks / outils de niveau entreprise comme Maven 3 / Spring 3 / Jersey / jQuery.

RESThub est très perturbateur par rapport à d'autres frameworks car il s'agit d'une boîte à outils pleine pile, mais sans aucun cadre de travail basé sur MVC ou servlet. Au lieu de cela, il utilise une interface graphique basée sur l'interface utilisateur jQuery qui utilise les services Web JAX-RS (REST) ​​et un système de modèles Javascript basé sur embeddedJs.

Les serveurs sont sans état et nous utilisons HTML5 sessionStorage pour conserver la session côté client. Cette approche est conçue pour RIA et évolutivité.

Certaines applications de démonstration sont fournies (même en cours de construction).

JSF est un bon framewrok, mais JSF 1.2 a manqué de vision pendant des années depuis sa sortie. JSF 2.0 semble prometteur et a beaucoup de nouvelles choses ajoutées à partir de JSF 1.2 comme la prise en charge d'ajax, les facettes, la prise en charge des annotations et les conventions par défaut (moins de XML), la création de composants facile que la 1.2.

Il s'intègre bien avec Spring également, si vous êtes préoccupé par le support DI.

J'appuierais la recommandation du printemps. Je ne suis pas un grand fan de GWT, je ne pense pas que le crosscompiler Java -> Javascript soit encore là. Je travaille sur une application AJAX qui utilise spring sur le serveur et jQuery sur le client. Bien qu'il n'y ait techniquement pas de support "out-of-the-box" pour jQuery, l'implémentation d'un Spring-MVC AjaxView est extrêmement simple et a pris environ 25 lignes de code.

Peut-être un peu en retard au spectacle, mais je dois mentionner Vaadin . La programmation se fait exclusivement en Java, avec une approche basée sur les composants. La communication client-serveur concerne davantage l'interaction utilisateur que le transport de données, toute la logique métier réside sur le serveur.

Ext GWT + ressort

Je pense que vous recherchez quelque chose de proche de Jahia. Il prend en charge GWT, les mashups, le contenu multimédia, etc.

http://www.jahia.org/cms/lang/en/home/Jahiapedia/Jahia_Templates http://www.jahia.net/downloads/jahia/jahia6.0.0/readme/index.html

LOGICIEL DU PORTAIL BACKBASE

Il y a quelques années, j'ai utilisé le logiciel de portail " Backbase " qui n'était pas très mûr à l'époque. Mais c'était bon et facile à développer.

Jetez un œil à ItsNat

ItsNat est essentiellement un navigateur Java W3C sur serveur, incroyablement simple (DHTML sur serveur), promouvant des applications d' interface à page unique intensive AJAX .

Les frameworks RIA basés sur les joueurs sont quelque chose qui mérite plus qu'une simple balle. Ex. Adobe Flex + Java (Bien sûr, cela peut dépendre quelque peu de savoir si votre "site" est vraiment un "site" ou plutôt une "application", vous ne feriez pas un site de blog dans Flex.)

ajax,

Dans le sens AJAX comme un mot à la mode, Flex utilise généralement AMF (un protocole binaire plus efficace que les protocoles utilisés par les applications AJAX), bien que vous puissiez également faire des choses strictement AJAX avec Flex. Donc Flex prend en charge AJAX, mais prend également en charge «mieux que AJAX».

contenu rich media, mashup,

Étant donné que Flex fonctionne sur la plate-forme de «machine virtuelle» Flash, je pense que peu de choses doivent être ajoutées.

mise en page basée sur des modèles,

Je ne sais pas exactement à quoi cela aboutit, mais cela ressemble à Flex mxml.

validation,

Pris en charge bien sûr, bien que vous puissiez décider de faire des choses personnalisées si vous voulez avoir envie. (Ce n'est pas nécessaire.) La bonne chose est que vous pouvez devenir aussi sophistiqué que vous le souhaitez - ou pas.

séparation maximale du code html / java

Vous ne pouvez pas être plus séparé en utilisant une approche de développement de «machine virtuelle» comme Flex / Silverlight / JavaFX. Cela ne vous permet pas seulement de garder votre code de présentation séparé de votre logique côté serveur et de votre couche d'accès aux données - cela garantit qu'ils sont séparés. La `` virtualisation '' de votre environnement de développement vous offre une compatibilité inter-navigateurs, une plate-forme cible cohérente, pas de soucis concernant les nouveaux navigateurs ou les nouvelles versions de navigateur qui cassent votre application, des capacités de débogage haut de gamme de type Java et un produit final plus professionnel / impressionnant .