Escolhendo um Java Web Framework agora? [fechadas]

estamos no estágio de planejamento da migração de um site grande, construído em uma estrutura mvc desenvolvida sob medida para uma estrutura da web baseada em java, que fornece suporte interno para ajax, conteúdo rich media, mashup, layout baseado em modelos, validação, html máximo / separação de código java. Grails parecia uma boa escolha, no entanto, não queremos usar uma linguagem de script. Queremos continuar usando java. O layout baseado em modelo é uma das principais preocupações, pois pretendemos usar esse aplicativo da Web em vários sites com funcionalidade semelhante, mas com aparência e comportamento radicalmente diferentes.

A solução baseada em portal é uma boa opção para esse problema?

Quaisquer informações sobre o uso de "Spring Roo" ou "Play" serão muito úteis.

Eu encontrei posts semelhantes como este , mas tem mais de um ano. As coisas certamente mudaram nesse meio tempo!

EDIÇÃO 1: Obrigado pelas ótimas respostas! Este site está se tornando a melhor fonte única de informações sobre programadores nas trincheiras. No entanto, eu esperava mais informações sobre o uso de uma dupla portal-cms. Jahia parece mercadoria. Algo parecido?

A solução baseada em portal é uma boa opção para esse problema?

Pessoalmente, eu ficaria longe das soluções grandes e pesadas do Portal (elas geralmente matam a produtividade). Já ouvi boas coisas sobre Gatein, mas não tenho nenhuma experiência real com isso.

Quaisquer informações sobre o uso de "Spring Roo" ou "Play" serão muito úteis.

Sobre o Spring Roo, li respostas anteriores, como o Spring roo Vs (Wicket e Spring) e outras coisas pela Internet, mas ainda não estou convencido (talvez não esteja entendendo), não tenho certeza de sua maturidade e, mais importante, estou realmente me perguntando o que o SpringSource está fazendo com Grails e Roo (não, Grails vs Roo - por que o SpringSource está desenvolvendo duas tecnologias muito semelhantes? não me convence de que ambos sobreviverão).

Não posso falar muito sobre o Play. Eu já vi a demonstração como todo mundo, mas gostaria de ler o feedback da vida real. Até lá, eu vou esperar.

Encontrei posts semelhantes (...). As coisas certamente mudaram nesse meio tempo!

Sim e não :) Mas vamos ao inferno das estruturas de apresentação: não há uma resposta única para sua pergunta (como um ano atrás), existem dezenas de estruturas por aí e nenhum vencedor claro. Apenas para citar alguns:

• JSF: Muitos céticos sobre essa estrutura baseada em componentes, inclusive eu, então não sou o melhor para falar sobre isso, mas ...
• JSF 2 (+ CDI / Weld): Os céticos do JSF são incentivados ( por Gavin King ) a "dar uma segunda olhada". Na verdade, acho que o JSF 2 é uma grande melhoria, especialmente com o CDI, mas ... ainda é bastante novo (entenda, falta de retorno). Se você deseja adotar o Java EE 6, verifique-o.
• Wicket: Outra estrutura baseada em componentes que está recebendo mais atenção. Ouço principalmente coisas boas sobre isso: mais simples que JSF, design agradável, alta testabilidade, fácil de projetar HTML, etc. Você pode gostar.
• Tapeçaria: apenas não (veja Por que você parou de usar a tapeçaria? )
• Struts 2, Spring MVC, Stripes: frameworks baseados em ação. Tudo decente e cobrirá suas necessidades (pessoalmente, eu gosto do Stripes e sua convenção sobre a abordagem de configuração, consulte Stripes vs. Struts2 para ter uma idéia).
• GWT, Flex, Grails: talvez não sejam o que você está procurando. Eu realmente não posso falar sobre (versões recentes) do Flex e do GWT, mas eu sei que o Grails tem alguns fãs .

Na verdade, eu sugiro dar uma olhada na casa de Matt Raible apresentações , ele realmente fez um grande trabalho de comparar frameworks web, mostrando seus pontos fortes e fracos, recolhendo fatos e números, que mostram tendências ... Eu recomendo:

• Comparando JSF, Spring MVC, Stripes, Struts 2, Tapeçaria e Wicket (ainda não obsoleto)
• Estruturas Web do futuro: Flex, GWT, Rails e Grails (apenas para ter uma idéia de alternativas)
• Comparando o Kick-Ass Web Frameworks (este é o mais recente)

Realmente, dê uma olhada nessas apresentações, elas ajudarão você a encontrar uma estrutura apropriada (não há resposta única, mas você pode restringir a escolha por eliminação) e pode mudar seu ponto de vista.

Uso o Spring 3 e o Jquery há um tempo, mas ouvi falar do Play e tentei. Eu realmente gosto, o Play é um ótimo ajuste entre algo como PHP e os frameworks Java pesados, como o Spring.

As coisas que mais gosto no jogo são:

• É muito fácil obter um aplicativo de reprodução do zero, você precisa ir muito longe com a codificação e a configuração para obter um aplicativo simples na tela com o Spring (embora o Spring 3 tenha facilitado muito).
• O Spring Security é incrível, mas tem um custo de complexidade. O módulo de segurança do Play é muito simples e cobre as necessidades de provavelmente 90% dos aplicativos existentes.
• Você pode fazer uma alteração no código e pressionar a atualização no navegador para ver a alteração como no PHP, em vez de ter que fazer toda a reimplementação com estruturas baseadas em Servlet.
• As mensagens de erro são exibidas de maneira agradável e não tão enigmática na maioria das vezes. O jogo ainda precisa trabalhar no tratamento de erros
• Existe um mecanismo de plug-in para o Play que é bastante simples.
• A persistência de objeto é feita muito bem, pois um banco de dados em memória e JPA vem com a estrutura, portanto não há configuração de ferramentas externas de persistência de objeto. Ir do banco de dados na memória para um RDBMS real é uma alteração de uma linha no arquivo de configuração.
• A configuração do MVC é feita muito bem. A classe Model que você estende para criar seus objetos de domínio integra-se ao gerenciador de entidades JPA. Eles não são apenas do POJO.
• O mapeamento de URLs para controladores é simples e flexível e tudo em um arquivo de "rotas".
• Sempre que você cria um projeto, o Play lida com todas as dependências do jar e o Play possui um utilitário para eclipsar-se (ou qualquer IDE que você queira), para que ele importe diretamente para o seu IDE favorito.

Coisas que não gosto no Play

• A documentação ainda não chegou até o fim, muitos recursos não documentados ainda existem.
• A estrutura é o servidor, portanto você deve dedicar uma porta a cada aplicativo. Acho que alguém está trabalhando em um plug-in de host virtual, mas ainda não o vi em ação.
• É jovem, o projeto é incrível e a tecnologia é incrível, mas realmente precisa de mais desenvolvedores. Eu adoraria dedicar algum tempo, veremos.

A melhor escolha para mim é o Wicket . Separação clara da marcação e do código java. Muito fácil de escrever e usar componentes. Simples de usar Ajax, testabilidade. Você pode depurar diretamente em suas páginas / componentes e não recebe mensagens de erro enigmáticas da sua implementação JSF;)

Há também uma boa comparação wicket <--> JSF em termos de desempenho

As três principais opções para mim são (em ordem alfabética):

• JSF
• Spring MVC
• Struts 2

Eles:

• tenha um bom suporte a ajax
• permitem criar sites reais, não aplicativos (como o GWT)
• estável, bem documentado, amplamente utilizado
• MVC
• Java puro
• fácil integração com o Spring como middleware

O jogo é semelhante ao ROR, uma versão ROR em java

Em contraste com outras respostas, gostaria de destacar as desvantagens (IMHO) das estruturas da web populares:

JSF2 - Lançado e já envelhecido. Ainda restam apenas algumas notícias / artigos / postagens de blog / experiências. Eu sou cético. Ainda aguardando o próximo grande lançamento do Richfaces / Icefaces, que suporta totalmente o jsf 2 - atualmente apenas as versões alfa podem ser baixadas.

Struts 2 - Parece ser apenas uma coisa boa se você ainda depende de struts e deseja refatorar a maior parte do seu código. Caso contrário: não.

GWT - Não gosto da abordagem de página única e de java-> javascript. Não tenho certeza se uma sessão - várias visualizações / janelas podem ser facilmente alcançadas. Para mim, essa estrutura deve ser usada para aplicativos de Internet ricos em janelas únicas para usuários massivos.

Postigo - Abordagem agradável, mas um pouco detalhada e com menos documentação disponível (exceto o bom wicket no livro de ação, mas isso abrange apenas 1,3). Além disso, para mim, faltam grandes projetos que são construídos sobre ela. E atualmente não consigo ver para onde a estrada da wicket está viajando ou se ela já foi levada a um beco sem saída.

Spring MVC - Ainda não tentei isso, mas você deve incluir muitos jars (spring mess) em seu caminho de classe para trabalhar com essa estrutura corretamente. E depende do JSP (na maioria dos projetos), que considero já morto. E você obtém apenas uma estrutura MVC pura - todas as outras coisas (ajax e outras) precisam ser implementadas / integradas.

Listras - Uma estrutura MVC projetada pequena e agradável, mas com menos documentação, menos confirmações / confirmações, poucas versões, muito menos suporte do setor e muito menos atividade na lista de discussão.

Também estou curioso se perdi uma estrutura importante por aí (deixei a Tapeçaria intencionalmente) que pode ser uma opção para você (e também para mim também).

Tive grande sucesso com o JAX-RS . É o único Java Web Framework que possui algum tipo de especificação JSR e várias implementações diferentes da especificação de servlet e portlet (embora isso possa ser uma coisa ruim).

Uma coisa ruim e boa sobre Java é que você pode escolher e combinar estruturas (python também possui esse recurso / problema). É bom porque você não precisa colocar todos os seus ovos em uma cesta.

Aqui está uma receita geral da pilha de aplicativos da Web Java:

Javascript / Flash + Tratamento de solicitação / resposta + Injeção de dependência + Persistência

Javascript: JQuery, Protótipo, Dojo

Solicitação / resposta: Spring MVC, Stripes e meu JAX-RS favorito (Jersey, Apache CXF)

Injeção de Dependência: Mola, Guice

Persistência: JPA (Hibernate, armazenamento de aplicativos do Google), Hibernate, JDO e mais.

Eu também tive grande sucesso ao usar o AspectJ para tornar o Java "menos trabalhoso". Usando os mixins @Configurable e ITD da AspectJ, do Spring, você pode obter Rails como objetos de Domínio (isso é de fato o que o Roo faz, mas você não precisa do Roo para fazer isso).

Eu descobri que as listras são realmente eficazes e surpreendentemente leves ... ela pretende ser mais leve que as struts . Ouvi de amigos que são desenvolvedores da Web em tempo integral que não vale a pena se preocupar com o JSF, embora eu não tenha experiência em primeira mão e não possa apoiar isso com exemplos (!).

Dê uma olhada no RESThub , que segue os mesmos princípios que o Play! mas implementado reutilizando algumas estruturas / ferramentas de nível empresarial, como Maven 3 / Spring 3 / Jersey / jQuery.

O RESThub é muito perturbador em comparação com outras estruturas, pois é um kit de ferramentas de pilha completa, mas sem nenhum MVC do servidor ou framworks baseado em servlet. Em vez disso, ele usa uma GUI baseada em UI do jQuery que usa serviços da Web JAX-RS (REST) ​​e um sistema de modelos Javascript baseado em JSs incorporados.

Os servidores são sem estado e usamos o HTML5 sessionStorage para manter a sessão no lado do cliente. Essa abordagem é projetada para RIA e escalabilidade.

Alguns aplicativos de demonstração são fornecidos (mesmo que em construção).

O JSF é um bom framewrok, mas o JSF 1.2 não teve visão nos próximos anos a partir de seu lançamento. O JSF 2.0 parece promissor e tem muitas novidades adicionadas a partir do JSF 1.2, como suporte ajax, facelets, suporte a anotações e convenções padrão (menos XML), criação fácil de componentes que 1.2.

Também se integra bem ao Spring, se você estiver preocupado com o suporte ao DI.

Eu recomendaria a recomendação da primavera. Eu não sou um grande fã de GWT, eu não acho que o crosscompiler Java -> Javascript já esteja lá. Estou trabalhando em um aplicativo AJAX que usa spring no servidor e jQuery no cliente. Embora tecnicamente não exista suporte "pronto para uso" ao jQuery, a implementação de um Spring-MVC AjaxView é simples e requer cerca de 25 linhas de código.

Talvez um pouco tarde para o show, mas eu tenho que mencionar Vaadin . A programação é feita exclusivamente em Java, com uma abordagem baseada em componentes. A comunicação cliente-servidor é mais sobre a interação do usuário do que o transporte de dados, toda a lógica de negócios reside no servidor.

Ext GWT + Mola

Eu acho que o que você está procurando é algo próximo a Jahia. Ele suporta GWT, Mashups, conteúdo de mí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

SOFTWARE DO PORTAL DE BACKBASE

Alguns anos atrás, eles usavam o software de portal " Backbase ", mas isso não estava muito maduro. Mas foi bom e fácil para o desenvolvimento.

Dê uma olhada no ItsNat

O ItsNat é basicamente um navegador Java W3C no servidor, incrivelmente simples (DHTML no servidor), promovendo aplicativos de interface de página única intensivos em AJAX

Algo que merece mais do que apenas uma bala são as estruturas RIA baseadas em jogadores. Ex. Adobe Flex + Java (Claro que isso pode depender um pouco do fato de o seu "site" ser realmente um "site" ou mais como um "aplicativo", você não faria um blog no Flex.)

ajax,

No sentido AJAX como palavra-chave, o Flex normalmente usa AMF (um protocolo binário mais eficiente que os protocolos usados ​​pelos aplicativos AJAX), embora você também possa fazer coisas estritamente AJAX com o Flex. Portanto, o Flex suporta AJAX, mas também "melhor que AJAX".

conteúdo rich media, mashup,

Sendo que o Flex é executado na plataforma de 'máquina virtual' do Flash, acho que pouco precisa ser adicionado.

layout baseado em modelos,

Não tenho certeza do que isso está acontecendo exatamente, mas parece o Flex mxml.

validação,

Suportado, é claro, embora você possa decidir fazer algumas coisas personalizadas, se quiser ser sofisticado. (Não que você precise.) O bom é que você pode ficar tão sofisticado quanto quiser - ou não.

separação máxima de código html / java

Você não pode ficar mais separado usando uma abordagem de desenvolvimento de 'máquina virtual' como Flex / Silverlight / JavaFX. Isso não apenas permite que você mantenha seu código de apresentação separado da lógica do servidor e da camada de acesso a dados - garante que eles estejam separados. 'Virtualizar' seu ambiente de desenvolvimento oferece compatibilidade entre navegadores, uma plataforma de destino consistente, sem preocupações com novos navegadores ou novos lançamentos de navegador quebrando seu aplicativo, recursos de depuração semelhantes a java de primeira linha e um produto final com aparência mais profissional / impressionante .