Todo desenvolvedor que usa servlets hoje conhece JSP, uma tecnologia web inventada pela Sun Microsystems e que despendeu muito esforço para promover e desenvolver a tecnologia servlet. JSP separa o código HTML do servlet, acelerando assim o desenvolvimento de aplicações web e a manutenção de páginas. Na verdade, o documento oficial "Modelo de Desenvolvimento de Aplicativos" publicado pela Sun vai ainda mais longe: "A tecnologia JSP deve ser considerada um padrão, e os servlets podem ser considerados um complemento na maioria dos casos (Seção 1.9, 1999/12/15)." Ouça a versão de opiniões).
O objetivo deste artigo é ouvir uma avaliação da plausibilidade desta afirmação – comparando JSP a outra tecnologia baseada em servlets: motores de modelo.
Problemas com o uso direto de Servlets
Inicialmente, os servlets foram inventados e o mundo inteiro viu sua superioridade. Páginas da web dinâmicas baseadas em servlets podem ser executadas rapidamente, podem ser facilmente transferidas entre vários servidores e podem ser perfeitamente integradas ao banco de dados back-end. Os servlets são amplamente aceitos como a plataforma preferida para servidores web.
No entanto, o código HTML que normalmente é implementado de forma simples agora exige que o programador chame out.println() para cada linha de HTML, o que se tornou um problema sério em aplicações servlets reais. O conteúdo HTML deve ser implementado por meio de código, o que é uma tarefa tediosa e demorada para páginas HTML grandes. Além disso, os responsáveis pelo conteúdo web tiveram que contratar desenvolvedores para fazer todas as atualizações. Por esse motivo, as pessoas procuram uma solução melhor.
JSP chega!
JSP 0.90 apareceu. Nesta técnica você incorpora o código Java em um arquivo HTML e o servidor criará automaticamente um servlet para a página. JSP é considerado uma maneira fácil de escrever servlets. Todo HTML pode ser obtido diretamente sem a necessidade de chamar out.println(), e a pessoa responsável pelo conteúdo da página pode modificar o HTML diretamente sem correr o risco de quebrar o código Java.
No entanto, ter artistas de páginas e desenvolvedores trabalhando no mesmo arquivo não era o ideal, e incorporar Java em HTML provou ser tão embaraçoso quanto incorporar HTML em Java. Ainda é difícil ler uma confusão de código.
Como resultado, as pessoas amadureceram no uso de jsp e passaram a usar mais JavaBeans. Os beans contêm o código de lógica de negócios exigido pelo jsp. A maior parte do código JSP pode ser retirada e colocada no bean, deixando apenas uma pequena quantidade de marcação para chamar o bean.
Recentemente, as pessoas começaram a pensar que as páginas JSP dessa forma são realmente como visualizações. Eles se tornam um componente usado para exibir os resultados das solicitações dos clientes. Então as pessoas vão pensar, por que não enviar uma solicitação diretamente para a visualização? O que acontece se a visão alvo não for adequada para a solicitação? Afinal, muitas solicitações possuem múltiplas possibilidades de obter a visualização do resultado. Por exemplo, a mesma solicitação pode produzir uma página bem-sucedida, um relatório de erros de exceção do banco de dados ou um relatório de erros de parâmetros ausentes. A mesma solicitação pode produzir uma página em inglês ou em espanhol, dependendo da localidade do cliente. Por que o cliente deve enviar a solicitação diretamente para a visualização? Por que o cliente não deveria enviar a solicitação para algum componente genérico do servidor e deixar o servidor decidir o que a visualização JSP retorna
? Model 2" Design, este é um modelo baseado em model-view-controller definido em JSP 0.92. Nesse design, as solicitações são enviadas para um controlador de servlet, que executa a lógica de negócios e gera um “modelo” de dados semelhante para exibição. Esses dados são então enviados internamente para uma "visualização" JSP para exibição, fazendo com que a página JSP pareça um JavaBean incorporado regular. A página JSP apropriada pode ser selecionada para exibição com base na lógica interna do servlet responsável pelo controle. Dessa forma, o arquivo JSP se torna uma bela visualização de modelo. Este é outro desenvolvimento e tem sido elogiado por outros desenvolvedores até hoje.
Insira os Template Engines
e use o mecanismo de template para substituir o JSP de uso geral. O design subsequente se tornará mais simples, a sintaxe será mais simples, a mensagem de erro será mais fácil de ler. , e as ferramentas serão melhores. Várias empresas fabricaram tais motores, a mais famosa é provavelmente a WebMacro ( http://webmacro.org , da Semiotek), e seu motor é gratuito.
Os desenvolvedores devem entender que a escolha de um mecanismo de modelo para substituir o JSP oferece vantagens técnicas, que também são algumas das deficiências do jsp:
Problema nº 1: o código Java é muito modelado
. Embora seja considerado um design ruim, o JSP ainda tenta adicionar Java. código para a página da web. Isso é um pouco parecido com o que o Java fez uma vez, que foi uma modificação simplificada dos mecanismos de modelo C++ que também simplificou, removendo o código-fonte de nível inferior em jsp. Os mecanismos de modelo implementam um design melhor.
Pergunta nº 2: Exigindo código Java
É necessário escrever algum código Java na página JSP. Por exemplo, suponha que uma página determine o contexto raiz do aplicativo Web atual e leve à sua página inicial.
É melhor usar o seguinte código Java em JSP:
＜a href="＜%= request.getContextPath() %＞/index.html"＞Home page＜/a＞
Você poderia tentar evitar o código Java e usar a tag <jsp:getProperty> mas isso lhe daria seis strings ilegíveis:
<a href="<jsp:getProperty name="request"
property="contextPath"/＞/index.html"＞HomePage＜/a＞
Usando o mecanismo de modelo, não há código Java e sintaxe feia. Aqui está como ele é escrito em WebMacro sob os mesmos requisitos:
＜a href="$ Request.ContextPath ;/index.html">Página inicial</a>
No WebMacro, ContextPath é usado como um atributo da variável $Request, usando sintaxe semelhante ao Perl. Outros mecanismos de modelo usam outros tipos de sintaxe.
Olhando para outro exemplo, suponha que uma "visualização" avançada precise definir um cookie para registrar a configuração de cores padrão do usuário - esta tarefa provavelmente será concluída pela visualização e não pelo controlador do servlet. Deve haver tal código Java em JSP:
<
% Cookie c = new Cookie("colorscheme", "blue"); response.addCookie(c)
; "azul"
como o último íon, se desejar recuperar a configuração de cores no cookie original. Para JSP, podemos pensar em uma classe de ferramenta correspondente para ajudar, porque seria ridículo e difícil fazer coisas de baixo nível diretamente com getCookies(). Em JSP:
<% String corescheme = ServletUtils.getCookie(request, "colorscheme" %>
Não há necessidade de classes de ferramentas no WebMacro, geralmente: $Cookie.colorscheme.Value. Para artistas gráficos que escrevem JSP, qual sintaxe é mais fácil de aprender?
JSP 1.1 introduziu tags personalizadas que permitem que tags arbitrárias semelhantes a HTML executem código Java em segundo plano em páginas JSP. Isso terá algum valor, mas apenas se houver uma biblioteca de tags padronizada, amplamente conhecida, com todos os recursos e disponível gratuitamente. Atualmente não existe tal biblioteca de tags.
Problema nº 3: Tarefas simples ainda são cansativas
Mesmo tarefas simples, como incluir cabeçalhos e rodapés, ainda são muito difíceis em JSP. Suponha que haja um modelo de “cabeçalho” e um “rodapé” a serem incluídos em todas as páginas, e cada modelo deve conter o título da página atual no conteúdo.
A melhor maneira em JSP é:
＜% String title = "O título da página"%＞;
＜%@include arquivo="/header.jsp" %＞
...conteúdo da sua página...
＜%@ include file="/footer.jsp" %＞
Os designers de páginas devem se lembrar de não omitir o ponto e vírgula na primeira linha e definir o título como uma string. Além disso, /header.jsp e /footer.jsp devem estar no diretório raiz e devem ser arquivos totalmente acessíveis.
Incluir cabeçalhos e rodapés no WebMacro é relativamente simples:
#set $title = "The Page Title"
#parse "header.wm"
Seu conteúdo aqui
#parse "footer.wm"
Não há ponto-e-vírgula ou definições de título para os designers lembrarem, e os arquivos .wm podem ser colocados em um caminho de pesquisa personalizável.
Problema nº 4: Loops muito grossos
Fazer loop em JSP é difícil. Aqui, JSP é usado para imprimir repetidamente o nome de cada objeto ISP.
<%
Enumeração e = list.elements();
enquanto (e.hasMoreElements()) {
out.print("O próximo nome é ");
out.println(((ISP)e.nextElement()).getName());
out.print("<br>");
}
%>
Talvez haja tags definidas pelo usuário para fazer esses loops algum dia. O mesmo vale para “se”. As páginas JSP podem parecer um código Java estranho. E ao mesmo tempo, o loop webmacro é lindo:
#foreach $isp em $isps {
O próximo nome é $isp.Name <br>
}
Se necessário, a diretiva #foreach pode ser facilmente substituída por uma diretiva personalizada #foreach-backwards.
Se você usar jsp, pode ficar assim: (Aqui está uma possível tag <foreach>)
<foreach item="isp" list="isps">
O próximo nome é ＜jsp:getProperty name="isp" property="name"/＞ ＜br＞
＜/foreach＞
O designer naturalmente escolherá o primeiro.
Problema nº 5: Mensagens de erro inúteis
JSPs geralmente apresentam algumas mensagens de erro surpreendentes. Isso ocorre porque a página é primeiro convertida em um servlet e depois compilada. Boas ferramentas JSP podem aumentar relativamente a probabilidade de encontrar a localização de um erro, mas mesmo as melhores ferramentas não conseguem tornar todas as mensagens de erro facilmente legíveis. Devido ao processo de conversão, alguns erros podem ser impossíveis de serem identificados pela ferramenta.
Por exemplo, suponha que uma página JSP precise criar um título que seja comum a todas as páginas. Não há nada de errado com o seguinte código:
＜% static String title = "Global title" %＞
Mas o Tomcat fornecerá a seguinte mensagem de erro:
work/%3A8080%2F/JC_0002ejspJC_jsp_1.java:70: Declaração esperada.
contagem interna estática = 0;
^
Esta informação pensa que o script acima foi colocado no método _jspService() e variáveis estáticas não podem ser colocadas no método. A sintaxe deve ser <%! É difícil para os designers de páginas lerem essas mensagens de erro. Mesmo as melhores plataformas ficam aquém nesse aspecto. Mesmo mover todo o código Java para fora da página não resolve o problema. Além disso, o que há de errado com a seguinte expressão?
<% contagem %>
tomcat dá:
work/8080/_0002ftest_0002ejsptest_jsp_0.java:56: Contagem de classes não encontrada em
declaração de tipo.
contar
^
work/8080/_0002ftest_0002ejsptest_jsp_0.java:59: Declaração inválida.
out.write("rn");
^
Em outras palavras, é apenas uma marca que falta. Deve ser <%= contagem %>.
Como o mecanismo de modelo pode ser gerado diretamente a partir do arquivo de modelo sem qualquer tradução dramática em código, é muito fácil fornecer relatórios de erros apropriados. Por analogia, quando um comando da linguagem C é digitado na linha de comando do shell Unix, você não deseja que o shell gere um programa C para executar o comando, mas você só precisa que o shell simplesmente interprete o comando e execute-o, e reportar diretamente quaisquer erros.
Problema nº 6: a necessidade de um compilador
JSP requer um compilador colocado no servidor web. Isso se tornou problemático porque a Sun se recusou a desistir da biblioteca tools.jar que continha seu compilador javac. O servidor web pode incluir um compilador de terceiros, como o Jikes da IBM. Mas tal compilador não funciona perfeitamente em todas as plataformas (escrito em C++) e não conduz à construção de um servidor web Java puro. JSP possui uma opção de pré-compilação que ajuda, embora não seja perfeita.
Problema nº 7: desperdício de espaço
JSP consome memória extra e espaço no disco rígido. Para cada arquivo JSP de 30K no servidor, um arquivo de classe correspondente maior que 30K deve ser gerado. Duplica efetivamente o espaço no disco rígido. Considerando que um arquivo JSP pode facilmente incluir um grande arquivo de dados através de <%@ include> a qualquer momento, esta preocupação tem um significado muito prático. Ao mesmo tempo, os dados do arquivo de classe de cada JSP devem ser carregados na memória do servidor, o que significa que a memória do servidor deve salvar toda a árvore de documentos JSP para sempre. Algumas JVMs têm a capacidade de mover dados de arquivos de classe da memória; no entanto, o programador geralmente não tem controle sobre as regras de redeclaração, e a redeclaração pode não ser muito eficiente para sites grandes; Para mecanismos de modelo, o espaço é economizado porque nenhum segundo arquivo é gerado. Os mecanismos de modelo também fornecem aos programadores controle total sobre como os modelos são armazenados em cache na memória.
Existem também alguns problemas com o uso do mecanismo de modelo:
Problema nº 1 do modelo: Não está estritamente definido
O modo como o mecanismo de modelo deve funcionar não está estritamente definido. No entanto, em comparação com JSP, isso não é realmente muito importante. Ao contrário do JSP, os mecanismos de modelo não têm nenhum requisito especial para o servidor web - qualquer servidor que suporte servlets pode suportar mecanismos de modelo (incluindo servidores API 2.0, como Apache/JServ, eles). não apoie totalmente JSP)! Se a competição saudável pelo melhor design de mecanismo de modelo pudesse ter causado uma inovação deslumbrante, especialmente com a promoção do código aberto (permitindo que ideias se impulsionassem e se promovessem umas às outras), então o WebMacro de hoje será como Perl! . Não está estritamente definido, mas a promoção de organizações de código aberto é o seu padrão.
Problema de modelo nº 2: não reconhecido
Os mecanismos de modelo não são amplamente conhecidos. JSP ocupou um enorme mercado comercial e está profundamente enraizado no coração das pessoas. O uso de motores de modelo g só pode ser uma tecnologia alternativa que não é compreendida.
Problema de modelo nº 3: não implantado
Os mecanismos de modelo ainda não estão altamente configurados. Não há teste de desempenho e comparação entre mecanismo de modelo e JSP. Em teoria, uma implementação de mecanismo de modelo bem implementada deveria corresponder a um JSP bem implementado; no entanto, considerando que terceiros fizeram um esforço tão profundo para o jsp, apenas o jsp é bem implementado;
O papel do JSP
É claro que o JSP certamente terá o seu lugar no futuro. A semelhança entre JSP e ASP pode ser percebida até pelos nomes, eles diferem apenas em uma letra. Portanto, se as pessoas que usam ASP mudarem para Java, o ambiente JSP muito semelhante desempenhará um grande papel na promoção disso. O papel de manter esse relacionamento correspondente com o ASP também deve ser uma consideração importante para os designers que lançam o JSP.
A questão aqui, contudo, é que existe uma grande diferença entre o que beneficia os trabalhadores que se mudam para um novo ambiente e se essa é realmente a melhor forma de utilizar esse ambiente.
JSP mostra cada vez mais que está se tornando uma das tecnologias Java mais importantes e permite que as pessoas deixem o mundo ASP - assim, a Sun apoiará este forte caso de negócios, e os apoiadores da tecnologia relacionada a Java também darão maior apoio.
Porém, esta não é a melhor solução para a plataforma java. Isso fará com que a solução Java pareça uma solução sem Java.