Por que eu usaria um mecanismo de modelagem? jsp include e jstl vs tiles, freemarker, velocity, sitemesh

Estou prestes a escolher uma forma de organizar minha visualização (com spring-mvc, mas isso não deve importar muito)

Existem 6 opções, tanto quanto vejo (embora não sejam mutuamente exclusivas):

• Azulejos
• Sitemesh
• Freemarker
• Velocidade
• <jsp:include>
• <%@ include file="..">

Ladrilhos e Sitemesh podem ser agrupados; assim como Freemarker e Velocity . Qual dentro de cada grupo usar não é uma questão para esta discussão, há questões e discussões suficientes sobre isso.

Esta é uma leitura interessante , mas não consegue me convencer a usar tiles.

Minha pergunta é - o que esses frameworks oferecem que não pode ser feito corretamente com <@ include file=".."> e JSTL. Pontos principais (alguns retirados do artigo):

1. Incluindo partes das páginas, como cabeçalho e rodapé - não há diferença entre:

   <%@ include file="header.jsp" %>

   e

   <tiles:insert page="header.jsp" />

2. Definir parâmetros no cabeçalho - como título, meta tags, etc. Isso é muito importante, especialmente do ponto de vista de SEO. Com as opções de modelos, você pode simplesmente definir um espaço reservado que cada página deve definir. Mas então você pode em jsp com JSTL , usando <c:set>(na página de inclusão) e <c:out>(na página incluída)

3. Reorganização do layout - se você deseja mover a localização atual acima do menu ou a caixa de login acima de outro painel lateral. Se as inclusões de página (com jsp) não estiverem bem organizadas, talvez seja necessário alterar todas as páginas nesses casos. Mas se seu layout não for excessivamente complexo e você colocar as coisas comuns no cabeçalho / rodapé, não há nada com que se preocupar.

4. Acoplamento entre os componentes comuns e o conteúdo específico - não encontro um problema com isso. Se você quiser reutilizar algum fragmento, mova-o para uma página que não inclua nenhum cabeçalho / rodapé e inclua-o sempre que necessário.

5. Eficiência -<%@ include file="file.jsp" %> é mais eficiente do que qualquer outra coisa, porque é compilado uma vez. Todas as outras opções são analisadas / executadas muitas vezes.

6. Complexidade - todas as soluções não jsp requerem arquivos xml adicionais, inclusões adicionais, configurações de pré-processador, etc. Esta é uma curva de aprendizado e apresenta mais pontos potenciais de falha. Além disso, torna o suporte e as alterações mais tediosos - você precisa verificar uma série de arquivos / configurações para entender o que está acontecendo.

7. Marcadores de posição - a velocidade / marcador livre fornece algo mais do que JSTL? Em JSTL, você coloca o espaço reservado e usa o modelo (colocado no escopo da solicitação ou da sessão, pelos controladores) para preencher esses espaços reservados.

Portanto, convença-me de que devo usar qualquer uma das estruturas acima em vez de / além do JSP simples.

Alguns argumentos para Velocity (eu não usei o Freemarker):

• Potencial para reutilizar modelos fora de um contexto da web, como no envio de e-mails
• A sintaxe da linguagem de template do Velocity é muito mais simples do que JSP EL ou bibliotecas de tags
• Separação estrita da lógica de visualização de qualquer outro tipo de lógica - nenhuma opção possível de cair no uso de tags scriptlet e fazer coisas desagradáveis ​​em seus modelos.

Espaços reservados - o velocity / freemaker oferece algo mais do que JSTL? Em JSTL, você coloca o espaço reservado e usa o modelo (colocado no escopo da solicitação ou da sessão, pelos controladores) para preencher esses espaços reservados.

Sim, as referências são realmente o núcleo da VTL:

<b>Hello $username!</b>

ou

#if($listFromModel.size() > 1)
    You have many entries!
#end

Eficiência - <%@ include file="file.jsp" %>é mais eficiente do que qualquer outra coisa, porque é compilado uma vez. Todas as outras opções são analisadas / executadas muitas vezes.

Não tenho tanta certeza se concordo ou entendo este ponto. O Velocity tem uma opção de armazenar modelos em cache, o que significa que a árvore de sintaxe abstrata na qual eles são analisados ​​será armazenada em cache ao invés de lida do disco todas as vezes. De qualquer forma (e eu não tenho números sólidos para isso), Velocity sempre pareceu rápido para mim.

Reorganização do layout - se você deseja mover a localização atual acima do menu ou a caixa de login acima de outro painel lateral. Se as inclusões de página (com jsp) não estiverem bem organizadas, talvez seja necessário alterar todas as páginas nesses casos. Mas se seu layout não for excessivamente complexo e você colocar as coisas comuns no cabeçalho / rodapé, não há nada com que se preocupar.

A diferença é que, com uma abordagem JSP, você não reorganizaria esse layout em cada arquivo JSP que usa o mesmo cabeçalho / rodapé? Tiles e SiteMesh permitem que você especifique uma página de layout base (JSP, modelo Velocity, etc - ambos são estruturas JSP em seu coração) onde você pode especificar o que quiser e então apenas delegar a um fragmento / modelo de "conteúdo" para o conteúdo principal . Isso significa que haveria apenas um arquivo para mover o cabeçalho.

A escolha entre jsp:includee Tiles / Sitemesh / etc é a escolha entre simplicidade e poder que os desenvolvedores enfrentam o tempo todo. Claro, se você tem apenas alguns arquivos ou não espera que seu layout mude com frequência, use apenas jstle jsp:include.

Mas os aplicativos têm uma maneira de crescer incrementalmente e pode ser difícil justificar "interromper o novo desenvolvimento e retrofit tiles (ou alguma outra solução) para que possamos corrigir problemas futuros mais facilmente" , que é necessário se você não usar um solução complexa no início.

Se você tem certeza de que seu aplicativo sempre permanecerá simples, ou se você pode definir algum benchmark de complexidade do aplicativo, após o qual irá integrar uma das soluções mais complexas, eu recomendo não usar tiles / etc. Caso contrário, use-o desde o início.

Não vou convencê-lo a usar outras tecnologias. Pelo que eu sei, todos deveriam se limitar a JSP se funcionar para eles.

Eu trabalho principalmente com Spring MVC e considero JSP 2+ em combinação com SiteMesh a combinação perfeita.

SiteMesh 2/3

Fornece decoradores a serem aplicados às visualizações principalmente como obras de herança em outros mecanismos de modelagem. Esse recurso é impensável para trabalhar sem hoje.

JSP 2+

Pessoas alegando que o JSP tornará difícil evitar o código Java nos modelos é falso. Você simplesmente não deveria fazer isso e com esta versão é desnecessário fazer isso. A versão 2 suporta métodos de chamada usando EL, o que é uma grande vantagem em comparação com as versões anteriores.

Com as tags JSTL, seu código ainda será semelhante a HTML, por isso é menos complicado. O Spring oferece muito suporte para JSP por meio de taglibs, o que é muito poderoso.

Os taglibs também são fáceis de estender, portanto, personalizar seu próprio ambiente é muito fácil.

Um dos melhores argumentos para facelets (não em sua lista, mas vou apenas mencioná-lo) em oposição ao uso de JSP é que a compilação é integrada ao interpretador em vez de ser delegada ao compilador JSP. Isso significa que uma das coisas mais irritantes que tive com o JSF 1.1 - ter que alterar o atributo id em uma tag JSF circundante ao salvar uma alteração para que o mecanismo de tempo de execução descobrisse a alteração - foi embora, permitindo o salvamento no editor, recarregar no navegador de volta, junto com mensagens de erro muito melhores.

Uma boa tecnologia de visualização elimina a maioria e as mais irritantes instruções if / switch / condicional, a inclusão simples não. Usar uma tecnologia de visualização 'complexa' resulta em uma aplicação 'simples'.

Você não forneceu informações específicas sobre seus aplicativos. Por exemplo, eu não uso JSP apenas por alguns motivos:

É difícil evitar o uso de código Java em modelos JSP, então você quebra o conceito de visualização pura e, como resultado, você terá dificuldades para manter o código em vários lugares como visualização e controlador

JSP cria automaticamente contexto JSP que estabelece uma sessão. Eu posso querer evitar isso, no entanto, se seus aplicativos sempre usam sessão, isso não pode ser um problema para você

JSP requer compilação e se o sistema de destino não tiver compilador Java, qualquer pequeno ajuste exigirá o uso de outro sistema e então reimplante

O mecanismo JSP mínimo tem cerca de 500k de bytecode mais JSTL, portanto, pode não ser adequado para sistemas embarcados

O mecanismo de modelo pode gerar diferentes tipos de conteúdo do mesmo modelo, digamos carga útil JSON, página da web, corpo do e-mail, CSV e assim por diante.

Um programador não Java pode ter dificuldades para trabalhar com modelos JSP, quando pessoas não técnicas nunca tiveram dificuldade para modificar modelos regulares.

Eu estava fazendo a mesma pergunta há muito tempo e terminei escrevendo meu framework (certamente baseado em template engine) que estava livre de todas as desvantagens que eu vi em outras soluções. Nem é preciso dizer que é cerca de 100k de código de bytes.

Sei que isso soa como uma resposta inteligente, mas a verdade é que, se você não vê nenhuma vantagem em usar modelos em vez de código em seu projeto atual, é provavelmente porque em seu projeto atual, não há um .

Parte disso é sobre escala. Você pode pensar que includes são tão poderosos quanto, digamos, sitemesh, e isso certamente é verdade, pelo menos para um pequeno número de páginas (eu diria provavelmente cerca de 100), mas se você tiver vários milhares, isso começa a se tornar incontrolável. (Portanto, para o eBay não é necessário, para o Salesforce provavelmente é)

Além disso, como foi mencionado antes, o marcador livre e a velocidade não são específicos do servlet. você pode usá-los para qualquer coisa (modelos de correio, documentação offline, etc.). Você não precisa de um contêiner de Servlet para usar o marcador livre ou velocidade.

Por fim, seu ponto 5 é apenas parcialmente verdadeiro. Ele é compilado toda vez que é acessado, caso ainda não tenha sido. Isso significa que sempre que você mudar algo, você precisa se lembrar de excluir o diretório "trabalho" dos contêineres de servlet, para que ele recompile o JSP. Isso é desnecessário com um mecanismo de modelagem.

Os motores de modelagem TL; DR foram escritos para resolver algumas deficiências (percebidas ou reais) de JSP + JSTL. Se você deve usá-los ou não, depende inteiramente de seus requisitos e da escala de seu projeto.