Todos los desarrolladores que utilizan servlets en la actualidad conocen JSP, una tecnología web inventada por Sun Microsystems y que dedicó muchos esfuerzos a promover y desarrollar la tecnología de servlets. JSP separa el código HTML del servlet, acelerando así el desarrollo de aplicaciones web y el mantenimiento de páginas. De hecho, el documento oficial "Modelo de desarrollo de aplicaciones" publicado por Sun va aún más lejos: "La tecnología JSP debe considerarse como un estándar y los servlets pueden considerarse como un complemento en la mayoría de los casos (Sección 1.9, 1999/12/15). Escuchar versión opiniones).
El propósito de este artículo es escuchar una evaluación de la plausibilidad de esta afirmación, comparando JSP con otra tecnología basada en servlets: los motores de plantillas.
Problemas con el uso directo de servlets
Inicialmente, se inventaron los servlets y el mundo entero vio su superioridad. Las páginas web dinámicas basadas en servlets se pueden ejecutar rápidamente, se pueden transferir fácilmente entre múltiples servidores y se pueden integrar perfectamente con la base de datos back-end. Los servlets son ampliamente aceptados como la plataforma preferida para servidores web.
Sin embargo, el código HTML que normalmente se implementa de forma sencilla ahora requiere que el programador llame a out.println() para cada línea de HTML, lo que se ha convertido en un problema grave en las aplicaciones de servlet reales. El contenido HTML debe implementarse mediante código, lo cual es una tarea tediosa y que requiere mucho tiempo para páginas HTML grandes. Además, los responsables del contenido web tuvieron que contratar desarrolladores para realizar todas las actualizaciones. Por este motivo, la gente busca una solución mejor.
¡Llega JSP!
Apareció JSP 0.90. En esta técnica, incrustas código Java en un archivo HTML y el servidor creará automáticamente un servlet para la página. JSP se considera una forma sencilla de escribir servlets. Todo el HTML se puede obtener directamente sin tener que llamar a out.println(), y la persona responsable del contenido de la página puede modificar el HTML directamente sin correr el riesgo de romper el código Java.
Sin embargo, tener artistas de páginas y desarrolladores trabajando en el mismo archivo no era lo ideal, e incrustar Java en HTML resultó ser tan embarazoso como incrustar HTML en Java. Todavía es difícil leer un montón de código.
Como resultado, la gente maduró en el uso de jsp y utilizó más JavaBeans. Los beans contienen el código de lógica empresarial requerido por jsp. La mayor parte del código en JSP se puede sacar y poner en el bean, dejando sólo una cantidad muy pequeña de marcado para llamar al bean.
Recientemente, la gente ha comenzado a pensar que las páginas JSP de esta manera son realmente como vistas. Se convierten en un componente utilizado para mostrar los resultados de las solicitudes de los clientes. Entonces la gente pensará, ¿por qué no enviar una solicitud directamente a la vista? ¿Qué sucede si la vista de destino no es adecuada para la solicitud? Después de todo, muchas solicitudes tienen múltiples posibilidades para obtener la vista de resultados. Por ejemplo, la misma solicitud puede generar una página exitosa, un informe de error de excepción de la base de datos o un informe de error de parámetros faltantes. La misma solicitud puede producir una página en inglés o una página en español, dependiendo de la ubicación del cliente. ¿Por qué el cliente debe enviar la solicitud directamente a la vista? ¿Por qué el cliente no debería enviar la solicitud a algún componente genérico del servidor y dejar que el servidor decida qué devuelve la vista JSP?
Esto ha llevado a muchas personas a aceptar lo que se conoce como " Diseño de modelo 2", este es un modelo basado en modelo-vista-controlador definido en JSP 0.92. En este diseño, las solicitudes se envían a un controlador de servlet, que realiza la lógica empresarial y genera un "modelo" de datos similar para su visualización. Luego, estos datos se envían internamente a una "vista" JSP para su visualización, lo que hace que la página JSP parezca un JavaBean incorporado normal. Se puede seleccionar la página JSP adecuada para su visualización en función de la lógica interna del servlet responsable del control. De esta manera, el archivo JSP se convierte en una hermosa vista de plantilla. Este es otro desarrollo y ha sido elogiado por otros desarrolladores hasta el día de hoy.
Ingrese a Template Engines
y use el motor de plantillas para reemplazar el JSP de propósito general. El diseño posterior será más simple, la sintaxis será más simple y el mensaje de error será más fácil de leer. , y las herramientas serán mejores. Varias empresas han creado este tipo de motores, la más famosa es probablemente WebMacro ( http://webmacro.org , de Semiotek), y su motor es gratuito.
Los desarrolladores deben comprender que elegir un motor de plantillas para reemplazar a JSP proporciona tales ventajas técnicas, que también son algunas de las deficiencias de jsp:
Problema número 1: el código Java tiene demasiadas plantillas
Aunque se considera un mal diseño, JSP todavía intenta agregar Java. código a la página web. Esto es algo parecido a lo que alguna vez hizo Java, que fue una modificación simplificada de los motores de plantillas de C++ que también lo simplificó eliminando el código fuente de nivel inferior en jsp. Los motores de plantillas implementan un mejor diseño.
Pregunta #2: Requerir código Java
Es necesario escribir algún código Java en la página JSP. Por ejemplo, supongamos que una página determina el contexto raíz de la aplicación web actual y conduce a su página de inicio.
Es mejor utilizar el siguiente código Java en JSP:
＜a href="＜%= request.getContextPath() %＞/index.html"＞Página de inicio＜/a＞
Podría intentar evitar el código Java y utilizar la etiqueta
property="contextPath"/＞/index.html"＞HomePage＜/a＞
Al usar el motor de plantillas, no hay código Java ni una sintaxis fea. Así es como está escrito en WebMacro con los mismos requisitos:
＜a href="$ Request.ContextPath ;/index.html">Página de inicio
En WebMacro, ContextPath se usa como un atributo de la variable $Request, usando una sintaxis similar a Perl. Otros motores de plantillas usan otros tipos de sintaxis.
Mirando otro ejemplo, supongamos que una "vista" avanzada necesita configurar una cookie para registrar la configuración de color predeterminada del usuario; parece probable que esta tarea la complete la vista en lugar del controlador de servlet. Debe existir dicho código Java en JSP:
<% Cookie c = new Cookie("colorscheme", "blue"); respuesta.addCookie(c %>
No hay código Java en WebMacro:
#set $Cookie.colorscheme = "azul"
como último ion, si desea recuperar la configuración de color en la cookie original. Para JSP, podemos pensar en una clase de herramienta correspondiente para ayudar, porque sería ridículo y difícil hacer cosas de tan bajo nivel directamente con getCookies(). En JSP:
<% String colourscheme = ServletUtils.getCookie(request, "colorscheme" %>
No hay necesidad de clases de herramientas en WebMacro, generalmente: $Cookie.colorscheme.Value. Para los artistas gráficos que escriben JSP, ¿qué sintaxis es más fácil de aprender?
JSP 1.1 introdujo etiquetas personalizadas que permiten que etiquetas arbitrarias similares a HTML ejecuten código Java en segundo plano en páginas JSP. Esto tendrá algún valor, pero sólo si existe una biblioteca de etiquetas estandarizada, ampliamente conocida y con todas las funciones. Actualmente no existe tal biblioteca de etiquetas.
Problema #3: Las tareas simples siguen siendo agotadoras
Incluso las tareas simples, como incluir encabezados y pies de página, siguen siendo muy difíciles en JSP. Supongamos que hay una plantilla de "encabezado" y un "pie de página" que se incluirán en todas las páginas, y cada plantilla debe contener el título de la página actual en el contenido.
La mejor manera en JSP es:
＜% Título de cadena = "El título de la página" %＞;
＜%@ incluir archivo="/header.jsp" %＞
...el contenido de tu página...
＜%@ include file="/footer.jsp" %＞
Los diseñadores de páginas deben recordar no omitir el punto y coma en la primera línea y definir el título como una cadena. Además, /header.jsp y /footer.jsp deben estar en el directorio raíz y deben ser archivos totalmente accesibles.
Incluir encabezados y pies de página en WebMacro es relativamente simple:
#set $title = "El título de la página"
#parse "encabezado.wm"
Tu contenido aquí
#parse "footer.wm"
No hay punto y coma ni definiciones de títulos para que los diseñadores las recuerden, y los archivos .wm se pueden colocar en una ruta de búsqueda personalizable.
Problema #4: Bucles muy gruesos
Hacer bucles en JSP es difícil. Aquí, JSP se utiliza para imprimir repetidamente el nombre de cada objeto ISP.
<%
Enumeración e = list.elements();
mientras (e.hasMoreElements()) {
out.print("El siguiente nombre es ");
out.println(((ISP)e.nextElement()).getName());
salida.print("
");
}
%>
Quizás en algún momento habrá etiquetas definidas por el usuario para realizar estos bucles. Lo mismo ocurre con "si". Las páginas JSP pueden parecer un código Java extraño. Y al mismo tiempo, el bucle webmacro es hermoso:
#foreach $isp en $isps {
El siguiente nombre es $isp.Name
}
Si es necesario, la directiva #foreach se puede reemplazar fácilmente por una directiva personalizada #foreach-backwards.
Si usa jsp, puede quedar así: (Aquí hay una posible etiqueta
El siguiente nombre es ＜jsp:getProperty name="isp" property="name"/＞ ＜br＞
＜/foreach＞
El diseñador naturalmente elegirá el primero.
Problema #5: Mensajes de error inútiles
Los JSP a menudo tienen algunos mensajes de error sorprendentes. Esto se debe a que la página primero se convierte en un servlet y luego se compila. Las buenas herramientas JSP pueden aumentar relativamente la probabilidad de encontrar la ubicación de un error, pero ni siquiera las mejores herramientas pueden hacer que todos los mensajes de error sean fácilmente legibles. Debido al proceso de conversión, es posible que la herramienta no pueda identificar algunos errores.
Por ejemplo, supongamos que una página JSP necesita crear un título que sea común a todas las páginas. No hay nada de malo en el siguiente código:
＜% static String title = "Global title"＞
Pero Tomcat proporcionará el siguiente mensaje de error:
work/%3A8080%2F/JC_0002ejspJC_jsp_1.java:70: Se espera declaración.
recuento int estático = 0;
^
Esta información cree que el script anterior se coloca en el método _jspService() y no se permite colocar variables estáticas en el método. La sintaxis debe ser <% %>. A los diseñadores de páginas les resulta difícil leer estos mensajes de error. Incluso las mejores plataformas se quedan cortas en este sentido. Incluso sacar todo el código Java de la página no resuelve el problema. Además, ¿qué hay de malo en la siguiente expresión?
<% recuento %>
Tomcat da:
work/8080/_0002ftest_0002ejsptest_jsp_0.java:56: No se encontró el recuento de clases en
declaración de tipo.
contar
^
work/8080/_0002ftest_0002ejsptest_jsp_0.java:59: Declaración no válida.
out.write("rn");
^
En otras palabras, es sólo una marca faltante. Debería ser <%= recuento %>.
Dado que el motor de plantillas se puede generar directamente desde el archivo de plantilla sin ninguna traducción dramática al código, es muy fácil brindar informes de errores adecuados. Por analogía, cuando se escribe un comando en lenguaje C en la línea de comando del shell de Unix, no desea que el shell genere un programa C para ejecutar el comando, solo necesita que el shell simplemente interprete el comando y lo ejecute. e informar directamente cualquier error.
Problema #6: Necesidad de un compilador
JSP requiere un compilador ubicado en el servidor web. Esto se volvió problemático porque Sun se negó a entregar la biblioteca tools.jar que contenía su compilador javac. El servidor web puede incluir un compilador de terceros, como Jikes de IBM. Pero un compilador de este tipo no funciona correctamente en todas las plataformas (escrito en C++) y no es propicio para construir un servidor web Java puro. JSP tiene una opción de precompilación que ayuda, aunque no es perfecta.
Problema nº 7: Desperdicio de espacio
JSP consume memoria y espacio extra en el disco duro. Por cada archivo JSP de 30 KB en el servidor, se debe generar un archivo de clase correspondiente de más de 30 KB. Duplica efectivamente el espacio en el disco duro. Teniendo en cuenta que un archivo JSP puede incluir fácilmente un archivo de datos grande a través de <%@ include> en cualquier momento, esta preocupación tiene un significado muy práctico. Al mismo tiempo, los datos del archivo de clase de cada JSP deben cargarse en la memoria del servidor, lo que significa que la memoria del servidor debe guardar todo el árbol de documentos JSP para siempre. Algunas JVM tienen la capacidad de mover datos de archivos de clase desde la memoria; sin embargo, el programador generalmente no tiene control sobre las reglas para la redeclaración y la redeclaración puede no ser muy eficiente para sitios grandes; Para los motores de plantillas, se ahorra espacio porque no se genera ningún segundo archivo. Los motores de plantillas también brindan a los programadores un control total sobre cómo se almacenan las plantillas en la memoria caché.
También existen algunos problemas con el uso del motor de plantillas:
Problema de plantilla n.º 1: no está estrictamente definido
No está estrictamente definido cómo debería funcionar el motor de plantillas. Sin embargo, en comparación con JSP, esto en realidad no es muy importante. A diferencia de JSP, los motores de plantillas no tienen ningún requisito especial para el servidor web: cualquier servidor que admita servlets puede admitir motores de plantillas (incluidos servidores API 2.0 como Apache/JServ). no soporta completamente JSP)! Si una competencia sana por el mejor diseño de motor de plantillas podría haber causado una innovación deslumbrante, especialmente con la promoción del código abierto (permitiendo que las ideas se impulsen y promuevan entre sí), entonces la WebMacro de hoy será como Perl. No está estrictamente definido pero la promoción de organizaciones de código abierto es su estándar.
Problema de plantilla nº 2: no reconocido
Los motores de plantilla no son muy conocidos. JSP ha ocupado un enorme mercado comercial y está profundamente arraigado en los corazones de la gente. El uso de motores de plantillas g sólo puede ser una tecnología alternativa que no se comprende.
Problema de plantilla n.º 3: no implementado
Los motores de plantilla aún no están altamente configurados. No existen pruebas de rendimiento ni comparación entre el motor de plantillas y JSP. En teoría, una implementación de motor de plantillas bien implementada debería coincidir con un JSP bien implementado; sin embargo, considerando que terceros han hecho un impulso tan profundo para jsp, sólo jsp está bien implementado;
El papel de JSP
Por supuesto, JSP ciertamente tendrá su lugar en el futuro. La similitud entre JSP y ASP se puede ver incluso en los nombres, solo se diferencian en una letra. Por lo tanto, si las personas que usan ASP cambian a Java, un entorno JSP muy similar jugará un gran papel en la promoción. El papel de mantener esta relación correspondiente con ASP también debería ser una consideración clave para los diseñadores que lanzan JSP.
El punto aquí, sin embargo, es que hay una gran diferencia entre lo que beneficia a los trabajadores que se mudan a un nuevo entorno y si es realmente la mejor manera de utilizar ese entorno.
JSP está demostrando cada vez más que se está convirtiendo en una de las tecnologías Java más importantes y permite a las personas abandonar el mundo de ASP; por lo tanto, Sun respaldará este sólido argumento comercial y los partidarios de la tecnología relacionada con Java también brindarán un mayor apoyo.
Sin embargo, esta no es la mejor solución para la plataforma Java. Esto hará que la solución Java parezca una solución sin Java.