usar libreria jtls funciones etiquetas curso java jsp servlets jstl

java - jtls - libreria de etiquetas jsp



¿Alguien todavía está usando JSTL? (5)

Estaba a punto de retomar algunos programas web Java, ya que no había tocado Java durante un par de años. Recogí un libro O''Reilly bastante viejo que estaba sentado en mi biblioteca ( páginas 3 de Java Server Pages, cubre JSP 2.0 y JSTL 1.1 ) y comencé a hojear las páginas. Fui a descargar las últimas bibliotecas JSTL y noté que todavía están en la versión 1.1. Preguntándose, ¿JSTL está muerto?

Hay bastantes frameworks Java por ahí, pero a mí me parecen todos hinchados y la configuración XML es una locura. Me gusta Java como un lenguaje y me gusta el hecho de que se ejecuta en un servidor (como Tomcat), pero me gustaría programar aplicaciones web Java como si yo, por ejemplo, programara PHP. Para mí, JSP y Servlets son lo suficientemente buenos y una cosa tan práctica como JSTL parece facilitar la vida. Pero aparentemente el resto del mundo parece pensar de manera diferente.

¿Acaso no lo entiendo y es JSP, Servlets y JSTL para dinosaurios? ¿Debería mantenerme alejado de este enfoque por una buena razón? ¿O puedo quedarme con seguridad con mi servidor Tomcat, JSP y Servlets para construir mis aplicaciones y servicios web?


JSP, Servlets y JSTL siguen siendo la norma para el desarrollo web de Java. Otros marcos como JSF y GWT están ganando tracción y están experimentando un rápido desarrollo, pero siguen siendo una minoría.

JSTL no se ha modificado desde la versión 1.x, es cierto, pero eso se debe a que es bastante bueno y no necesita mucha mejora (usaría algunos, cierto, pero nada drástico).

Sin embargo, la API de servlet sin procesar no es la que quieres usar. Los marcos superpuestos sobre la API de Servlet (de los cuales hay más de lo que se puede sacudir un palo) son una apuesta mucho mejor. Sin embargo, en su mayoría usan JSP como su capa de vista predeterminada.


No, no está muerto. Es tan robusto que no es necesario mejorar / corregir nada :) Todavía lo usamos a diario. ¿Qué más usarías para controlar el flujo de presentación en JSP? Scriptlets? Oh, gracias, no.

Sin embargo, ya existe JSTL 1.2, que es básicamente una combinación de los dos archivos de los que originalmente existen ( jstl.jar y standard.jar ) junto con mejoras muy pequeñas.

Con respecto a los frameworks de los que habla, esos son principalmente frameworks MVC que se construyen sobre JSP / Servlet (e incluso JSTL).

pero me gustaría programar aplicaciones web Java como si, por ejemplo, programara PHP.

Yo diría que esa es una mala idea. Tal vez no, si se trata de un simple libro de visitas de una sola página o formulario de contacto, pero incluso entonces JSP sería demasiado desbordante. Simplemente quédate con PHP si quieres escribir / desordenar todo en una sola página. JSP / Java realmente no está allí para.

Para mí, JSP y Servlets son lo suficientemente buenos y una cosa tan práctica como JSTL parece facilitar la vida. Pero aparentemente el resto del mundo parece pensar de manera diferente.

No es necesario que utilice uno u otro marco, pero cuando la aplicación crece fuera de sus fronteras, sería feliz si ha elegido un marco MVC existente y robusto.

Sin embargo, con la mejorada API Servlet 3.0 y la impresionante API JAX-RS que salió junto con Java EE 6 la semana pasada, no creo que realmente necesite un framework.


Si desea tener un marco algo extremadamente simple pero al menos tan poderoso como JSP + JSTL, considere usar http://www.hybridserverpages.com . No requiere configuración como tal (excepto para web.xml ya que genera código encima de un servlet).



Todavía uso JSP (incluido JSTL) en aplicaciones.

Las viejas aplicaciones tienen una GUI algo exigente que me encantaría ver implementada en Wicket o en algún marco similar.

Sin embargo, implementaría tareas sencillas de administración en JSP (con spring-MVC o struts) porque es muy fácil de esa manera.

Sin embargo, no implementaría una GUI nueva y exigente con JSP a menos que la lógica de la GUI esté en javascript. Es demasiado difícil lidiar con los diferentes navegadores, y las demandas de personas con discapacidad (sin javascript) frente a javascript-heavy para las personas que pueden disfrutarlo. Me gusta que mi marco haga eso por mí.