Benefícios do uso JSTL vs Velocity para visualização da camada no MVC aplicativo?

Question

Atualmente estou construindo uma aplicação Spring MVC. Eu estava olhando para usar páginas JSP com bibliotecas de tags para lidar com a camada de visão e formatação do HTML, mas eu me deparei com outro grupo na minha empresa que modelos de usos de velocidade para a mesma finalidade.

Pelo que posso ver, parece-me como se há um monte de semelhanças entre as duas abordagens:

1. Ambos têm fácil de entender sintaxe. Torna mais fácil para não-desenvolvedores de entender e usar, permitindo que os designers se concentrar no HTML / CSS e só ter que usar directivas / bibliotecas de tags, nos poucos casos em que eles precisam condicionais / conteúdo dinâmico sem ter que ter um entendimento completo de Java.
2. Simples para ver qual parte do conteúdo é HTML vs que são directivas / lógica.
3. Ambos são muito utilizadas e bem suportado.
4. Simples de integrar com Spring MVC.

Mas na comparação entre as duas tecnologias, não vejo quaisquer razões específicas para a utilização de um contra o outro. Estou tendo problemas para pensar de qualquer contras específicos para cada Velocity ou JSTL.

Então, minha pergunta é, quais são os prós e contras de cada um na sua opinião? Se você construiu um aplicativo (Primavera) MVC usando um ou o outro, o que fez você decidir sobre a tecnologia de camada de visão que você está usando eo que (se alguma coisa) fez você decidir contra o outro?

Atualizar : Eu encontrei uma discussão semelhante de este mesmo tópico arquivado na do fórum Spring Framework aqui , que pode ser de algum interesse para qualquer pessoa fazendo a mesma decisão entre JSTL e Velocity como eu sou.

Answer 1

Eu preferiria usar Velocity só porque usando JSP + JSTL pode permitir preguiçosos desenvolvedores / desleixado de entrar em apuros, acrescentando scriptlets. Não deve haver nenhuma razão para ter código java na sua opinião camada. Não é preciso muito para entender Velocity e como uma questão de fato, eu só peguei-o em cerca de duas semanas. Embora eu não gosto da formatação da saída, para a maior parte funciona muito bem. Nós realmente não o estiver usando, tendo em vista camada do aplicativo, mas sim para a geração de HTML para uso por outros navegadores. Nós salvar a saída de Velocity como arquivos que depois é implantado para um servidor diferente para o consumo por outros clientes web.

Answer 2

Eu realmente prefiro ligeiramente Freemarker para Velocity, apenas no caso que você está aberto para explorar outras opções. Comparação aqui:

http://freemarker.org/fmVsVel.html

Eu concordo com as declarações de Ben cerca de impor uma visão simples, evitando JSP ea possibilidade de scriptlets. Eu também gosto da capacidade de tornar um modelo Freemarker ou Velocity em qualquer tipo de ambiente de execução (JUnit, o método main ()) sem a necessidade de um recipiente Servlet / JSP como JSP faria.

Answer 3

JSP também é mais difícil diferenciar visualmente a partir do HTML incorporado. Com velocidade, é muito óbvio.

Além disso, o pacote VelocityTools fornece uma grande quantidade de funcionalidades adicionais.