Scegli un Java Web Framework ora? [chiuso]

siamo nella fase di pianificazione della migrazione di un grande sito Web basato su un framework mvc sviluppato su misura per un framework Web basato su Java che fornisce supporto integrato per ajax, contenuti multimediali, mashup, layout basato su modelli, convalida, html massimo / separazione del codice java. Grails sembrava una buona scelta, tuttavia, non vogliamo usare un linguaggio di scripting. Vogliamo continuare a utilizzare Java. Il layout basato su modelli è una delle principali preoccupazioni in quanto intendiamo utilizzare questa applicazione Web con più siti Web con funzionalità simili ma aspetto e aspetto radicalmente diversi.

La soluzione basata su portale è adatta a questo problema?

Qualsiasi approfondimento sull'uso di "Spring Roo" o "Play" sarà molto utile.

Ho trovato post simili come questo , ma ha più di un anno. Le cose sono sicuramente cambiate nel frattempo!

EDIT 1: Grazie per le ottime risposte! Questo sito sta diventando la migliore fonte singola per le informazioni sui programmatori nelle trincee. Tuttavia, mi aspettavo maggiori informazioni sull'uso di un duo portal-cms. Jahia sembra merce. Qualcosa di simile?

La soluzione basata su portale è adatta a questo problema?

Personalmente, starei alla larga dalle grandi e grosse soluzioni del portale (spesso sono dei killer della produttività). Ho sentito cose positive su Gatein però, ma non ho alcuna esperienza reale con esso.

Qualsiasi approfondimento sull'uso di "Spring Roo" o "Play" sarà molto utile.

A proposito di Spring Roo, ho letto le risposte precedenti come Spring roo Vs (Wicket e Spring) e altre cose su Internet ma non sono ancora convinto (forse non capisco), non sono sicuro della sua maturità e, cosa più importante, mi sto davvero chiedendo cosa sta facendo SpringSource con Grails e Roo (no, Grails vs Roo - perché SpringSource sta spingendo due tecnologie molto simili? Non mi convince che sopravviveranno entrambi).

Non posso dire molto su Play. Ho visto la demo come tutti, ma mi piacerebbe leggere i feedback sulla vita reale. Fino ad allora, aspetterò.

Ho trovato post simili (...). Le cose sono sicuramente cambiate nel frattempo!

Sì e no :) Ma entriamo nell'inferno dei framework di presentazione: non esiste una sola risposta alla tua domanda (come un anno fa), ci sono dozzine di framework lì intorno e nessun chiaro vincitore. Solo per citarne alcuni:

• JSF: Molti scettici su questo framework basato su componenti, incluso me, quindi non sono il migliore a parlarne ma ...
• JSF 2 (+ CDI / Weld): gli scettici JSF sono incoraggiati ( da Gavin King ) a "dare una seconda occhiata". In effetti, penso che JSF 2 sia un grande miglioramento, specialmente con CDI, ma ... è ancora piuttosto nuovo (capisci, manca di feeback). Se vuoi abbracciare Java EE 6, dai un'occhiata però.
• Wicket: un altro framework basato su componenti che sta suscitando maggiore attenzione. Sento soprattutto cose positive: più semplice di JSF, design accattivante, alta testabilità, progettazione HTML, ecc. Potrebbe piacerti.
• Tapestry: Semplicemente no (vedi Perché hai smesso di usare Tapestry? )
• Struts 2, Spring MVC, Stripes: framework basati sull'azione. Tutto decente e coprirà le tue esigenze (personalmente, mi piace Stripes e la sua convenzione sull'approccio alla configurazione, vedi Stripes vs. Struts2 per averne un'idea).
• GWT, Flex, Grails: forse non sono quello che stai cercando. Non posso davvero parlare di (versioni recenti) di Flex e GWT ma so che Grails ha alcuni fan .

In realtà, suggerirei di dare un'occhiata alle presentazioni di Matt Raible , ha fatto davvero un ottimo lavoro nel confrontare i framework web, mostrando i loro punti di forza e debolezza, raccogliendo fatti e numeri, mostrando tendenze ... Consiglio:

• Confronto tra JSF, Spring MVC, Stripes, Struts 2, Tapestry e Wicket (ancora non obsoleto)
• Web Frameworks of the Future: Flex, GWT, Rails and Grails (solo per avere un assaggio delle alternative)
• Confronto tra i Web Frame Kick-Ass (questo è il più recente)

Davvero, dai un'occhiata a queste presentazioni, ti aiuteranno a trovare un framework adeguato (non esiste una risposta unica ma puoi limitare la scelta eliminandola) e potrebbero cambiare il tuo punto di vista.

Sto usando Spring 3 e Jquery da un po ', ma ho sentito parlare di Play e ci ho provato. Mi piace molto, Play si adatta perfettamente a qualcosa come PHP e ai framework Java heavy duty come Spring.

Le cose che mi piacciono di più del gioco sono:

• Molto facile ottenere un'applicazione di gioco da terra, devi andare abbastanza lontano con la codifica e la configurazione per ottenere una semplice applicazione grezza sullo schermo con Spring (anche se Spring 3 ha reso molto più facile).
• Spring Security è eccezionale ma ha un costo di complessità. Il modulo di sicurezza di Play è molto semplice e copre probabilmente il 90% delle applicazioni disponibili.
• È possibile apportare una modifica al codice e premere Aggiorna nel browser per vedere la modifica come con PHP invece di dover eseguire l'intera operazione di ridistribuzione con i framework basati su Servlet.
• I messaggi di errore vengono visualizzati correttamente e non così criptici per la maggior parte del tempo. Il gioco deve ancora lavorare sulla gestione degli errori
• C'è un meccanismo di plugin per Play che è piuttosto semplice.
• La persistenza degli oggetti viene eseguita molto bene in quanto un database in memoria e JPA vengono forniti con il framework, quindi non esiste alcuna configurazione di strumenti di persistenza degli oggetti esterni. Passare dal database in memoria a un RDBMS effettivo è una modifica di una riga nel file di configurazione.
• L'impostazione MVC è fatta molto bene. La classe Model che estendi per creare i tuoi oggetti di dominio si integra con il gestore entità JPA. Non sono solo POJO.
• Il mapping degli URL ai controller è semplice e flessibile e tutto in un unico file "route".
• Ogni volta che crei un progetto, Play gestisce tutte le dipendenze jar e Play ha un'utilità per eclissare (o qualunque IDE ti piaccia) il progetto in modo che venga importato direttamente nel tuo IDE preferito.

Cose che non mi piacciono di Play

• La documentazione non è ancora del tutto lì, esistono ancora molte funzionalità non documentate.
• Il framework è il server, quindi è necessario dedicare una porta a ciascuna applicazione. Penso che qualcuno stia lavorando su un plug-in host virtuale ma non l'ho ancora visto in azione.
• È giovane, il progetto è fantastico e la tecnologia è fantastica ma ha davvero bisogno di altri sviluppatori. Mi piacerebbe dedicarci un po 'di tempo, vedremo.

La scelta migliore per me è Wicket . Chiara separazione tra markup e codice java. Componenti molto facili da scrivere e usare. Ajax semplice da usare, testabilità. Puoi eseguire il debug direttamente nelle tue pagine / componenti e non ottenere messaggi di errore criptici dalla tua implementazione JSF;)

C'è anche un buon paragone wicket <--> JSF in termini di prestazioni

Le tre scelte principali per me sono (in ordine alfabetico):

• JSF
• Spring MVC
• Puntoni 2

Essi:

• avere un buon supporto Ajax
• consentono di creare siti Web effettivi, non applicazioni (come GWT)
• stabile, ben documentato, ampiamente utilizzato
• MVC
• Java puro
• facile integrazione con Spring come middleware

Il gioco è molto simile a ROR, una versione ROR di Java

Contrariamente ad altre risposte, vorrei evidenziare gli svantaggi (IMHO) dei popolari framework Web:

JSF2 - Rilasciato e già invecchiato. Ancora poche notizie / articoli / post di blog / esperienze fuori. Sono scettico Aspetto ancora la prossima versione principale di Richfaces / Icefaces che supporta pienamente jsf 2: attualmente è possibile scaricare solo build alpha.

Struts 2 - Sembra essere solo una buona cosa se stai ancora facendo affidamento su struts e vuoi rifattorizzare la maggior parte del tuo codice. Altrimenti: no.

GWT - Non mi piace l'approccio a pagina singola e java-> javascript. Non sono sicuro se una sessione - più viste / finestre possono essere facilmente raggiunte. Per me, questo framework dovrebbe essere utilizzato per applicazioni Internet a finestra singola ricche di utenti di massa.

Wicket - Approccio piacevole, ma un po 'dettagliato e troppa meno documentazione disponibile (tranne il buon wicket nel libro d'azione, ma questo copre solo 1.3). Inoltre, per me manca di grandi progetti che si basano su di esso. E al momento non riesco a vedere dove sta percorrendo la strada del wicket o se è già stato condotto in un vicolo cieco.

Spring MVC - Non l'ho ancora provato, ma devi includere molti vasi (pasticcio di primavera) nel tuo percorso di classe per funzionare correttamente con questo framework. E si basa su JSP (nella maggior parte dei progetti), che considero già morto. E ottieni solo un framework MVC puro - tutte le altre cose (ajax e altre) devono essere implementate / integrate.

Stripes : un framework MVC piccolo e ben progettato, ma troppa documentazione, troppi commit / commit, troppi rilasci, troppo meno supporto del settore, troppa attività di mailing list.

Sono anche curioso di sapere se ho perso un quadro importante là fuori (ho lasciato intenzionalmente Tapestry) che potrebbe essere un'opzione per te (e anche per me).

Ho avuto un grande successo con JAX-RS . È l'unico Java Web Framework che ha una sorta di specifica JSR e molteplici implementazioni diverse dalle specifiche servlet e portlet (anche se questa può essere una cosa negativa).

Una cosa negativa e positiva di Java è che puoi scegliere e abbinare i framework (anche python ha questa caratteristica / problema). È bello perché non devi mettere tutte le uova nello stesso paniere.

Ecco una ricetta generale dello stack di applicazioni Web Java:

Javascript / Flash + Gestione richieste / risposte + Iniezione dipendenze + Persistenza

Javascript: JQuery, Prototype, Dojo

Richiesta / Risposta: Spring MVC, Stripes e il mio preferito JAX-RS (Jersey, Apache CXF)

Iniezione delle dipendenze: primavera, Guice

Persistenza: JPA (Hibernate, Google App storage), Hibernate, JDO e altro.

Ho anche avuto un grande successo nell'uso di AspectJ per rendere Java "succhiare meno". Usando i mixin ITD di Spring @Configurable e AspectJ puoi ottenere Rails come oggetti Domain (questo è esattamente ciò che fa Roo ma non hai bisogno di Roo per farlo).

Ho trovato le strisce davvero efficaci e sorprendentemente leggere ... mira ad essere più leggera delle molle . Ho sentito da amici che sono sviluppatori web a tempo pieno che non vale la pena preoccuparsi di JSF, anche se non ho esperienza diretta e non posso sostenerlo con esempi (!).

Dai un'occhiata a RESThub , che segue gli stessi principi di Play! ma implementato riutilizzando alcuni framework / strumenti di livello enterprise come Maven 3 / Spring 3 / Jersey / jQuery.

RESThub è molto dirompente rispetto ad altri framework poiché è un toolkit full stack, ma senza MVC lato server o framwork basati su servlet. Al contrario, utilizza una GUI basata su UI jQuery che utilizza i servizi Web JAX-RS (REST) ​​e un sistema di template Javascript basato su embeddedJs.

I server sono apolidi e usiamo HTML5 sessionStorage per mantenere la sessione sul lato client. Questo approccio è progettato per RIA e scalabilità.

Vengono fornite alcune applicazioni demo (anche se in costruzione).

JSF è un bel framewrok, ma JSF 1.2 mancava di visione per gli anni a venire dalla sua uscita. JSF 2.0 sembra promettente e ha molte nuove cose aggiunte da JSF 1.2 come supporto ajax, facelets, supporto di annotazioni e convenzioni predefinite (meno XML), costruzione di componenti facile rispetto a 1.2.

Si integra bene anche con Spring, se sei preoccupato per il supporto DI.

Secondo la raccomandazione di primavera. Non sono un grande fan di GWT, non credo che il crosscompiler Java -> Javascript sia ancora lì. Sto lavorando su un'app AJAX che utilizza spring sul server e jQuery sul client. Anche se tecnicamente non esiste un supporto "out-of-the-box" per jQuery, l'implementazione di AjaxView di Spring-MVC è estremamente semplice e richiede circa 25 righe di codice.

Forse un po 'in ritardo per lo spettacolo, ma mi hanno menzionare Vaadin . La programmazione viene eseguita esclusivamente in Java, con un approccio basato sui componenti. La comunicazione client-server riguarda più l'interazione dell'utente che il trasporto di dati, tutta la logica aziendale risiede sul server.

Ext GWT + Spring

Penso che quello che stai cercando sia qualcosa vicino a Jahia. Supporta GWT, Mashup, contenuti multimediali ecc.

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

SOFTWARE PORTALE BACKBASE

Un paio d'anni fa ho usato il portale " Backbase " che non era molto maturo. Ma era buono e facile per lo sviluppo.

Dai un'occhiata a ItsNat

ItsNat è fondamentalmente un browser Java W3C server, incredibilmente semplice (DHTML nel server), promuovendo AJAX intensiva Pagina singola interfaccia applicazioni

Qualcosa che merita più di un semplice proiettile sono i framework RIA basati sui giocatori. Ex. Adobe Flex + Java (Naturalmente questo può dipendere in qualche modo dal fatto che il tuo "sito" sia davvero un "sito" o più come una "applicazione", non faresti un sito blog in Flex.)

ajax,

Nel senso di AJAX come parola d'ordine, Flex usa tipicamente AMF (un protocollo binario che è più efficiente dei protocolli usati dalle app AJAX), anche se puoi anche fare cose rigorosamente AJAX con Flex. Quindi Flex supporta AJAX, ma supporta anche "meglio di AJAX".

contenuti multimediali, mashup,

Dato che Flex funziona sulla piattaforma "macchina virtuale" di Flash, penso che poco debba essere aggiunto.

layout basato su modelli,

Non sono sicuro di cosa stia ottenendo esattamente, ma sembra Flex mxml.

convalida,

Supportato ovviamente, anche se potresti decidere di fare alcune cose personalizzate se vuoi essere sofisticato. (Non che devi farlo.) La cosa bella è che puoi diventare sofisticato quanto vuoi - o no.

massima separazione del codice html / java

Non puoi essere più separato usando un approccio di sviluppo "macchina virtuale" come Flex / Silverlight / JavaFX. Questo non solo ti consente di mantenere il tuo codice di presentazione separato dalla tua logica lato server e dal livello di accesso ai dati, ma ti assicura che siano separati. La "virtualizzazione" del tuo ambiente di sviluppo ti offre compatibilità cross-browser, una piattaforma di destinazione coerente, nessuna preoccupazione per i nuovi browser o le nuove versioni del browser che infrangono la tua applicazione, funzionalità di debug di alto livello simili a java e un prodotto finale dall'aspetto più professionale / impressionante .