Llamadas de método en EL

Question

Cuando escribo Java webapps, generalmente uso etiquetas JSTL. Creo que estas etiquetas son geniales, a excepción de una cosa que me molesta: mientras que el lenguaje de expresión le permite acceder a las propiedades de frijol, no le permite llamar a sus métodos.

En la versión 1.0, ni siquiera fue posible obtener la longitud de una cadena o la cantidad de elementos de una colección. A partir de la versión 1.1, la función fn: longitud se ha añadido, por lo que puede hacer cosas como esta:

... 
<%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %> 
... 
<c:if test="${fn:length(str) > 10}"> 
    ... 
</c:if> 
... 

¿Qué es más detallado y más fea (en mi humilde opinión es que):

... 
<c:if test="${str.length() > 10}"> 
    ... 
</c:if> 
... 

Parece que JSTL 2.0 le permitirá definir nuevas funciones, pero necesitará escribir una clase específicamente para ese propósito, en la cual definirá sus métodos (estáticos) y también necesitará escribir un archivo TLD que lo haga ser incluido en cada jsp que usará estas funciones.

Ya sea que defina una función personalizada o use otra solución alternativa, tiene mucho código adicional para escribir.

He leído en alguna parte que el JCP ha rechazado voluntariamente la invocación de métodos desde el lenguaje de expresiones.

¿Alguien puede ayudarme a entender por qué diablos el JCP nos está haciendo esto?

Answer 1

La función que desea se define en JSR 245 (more here). Si lo quiere ahora, descárguelo desde el UEL project o una implementación alternativa (por ejemplo, JUEL). Si necesita esperar a que sea parte del estándar, se incluirá en JEE6. Hasta entonces ... bueno, ya sabes tus opciones.

Answer 2

Espero que el objetivo sea imponer una separación estricta de la vista de modelo, como en StringTemplate.

La idea es bastante simple: si no tiene acceso a los métodos, entonces se ve obligado a calcular todos sus datos en el controlador y luego simplemente formatearlo en la vista. Por supuesto, enturbiaron el mensaje permitiéndole tener acceso a las funciones y no les ayudó el hecho de que no es tan fácil crear listas de mapas de tuplas (léase: datos estructurados sin clases) en Java, como lo es en Python, Ruby, etc.

De todos modos, aquí hay un artículo sobre cómo escribir una etiqueta que le permite llamar al arbitrary methods, puede que le sea útil.

Answer 3

¿Alguien puede ayudarme a entender por qué diablos el JCP nos está haciendo esto?

Forma parte de la mentalidad bondage and discipline de un cierto subconjunto de programadores de Java que conoce The One True Way que todo el mundo debería crear aplicaciones.

No se puede confiar en que tenga un lenguaje completo a su disposición cuando escriba plantillas, porque puede abusar de él para mezclar la lógica de negocios y la presentación, como esos horribles y groseros codificadores de PHP. Eurgh, ¡imagínate!

El programador es el enemigo, y debe evitarse que haga mal. Puede ser que el programador simplemente esté tratando de depurar algo, o que haya un truco rápido para que la aplicación se ejecute temporalmente.O podría ocurrir que exista una lógica de presentación, y hacer que muevas esas cosas a un montón de clases de etiquetas y beans en tu aplicación es tan desagradable como al revés.

¡Pero no importa! Vale la pena molestarte para servir al propósito de defender la castidad de Java.

[Lo siento por el snark, pero ya era una pregunta bastante Ranty eh.]

PS. Siempre hay Groovy, supongo.

Answer 4

¡Echa un vistazo a Seam! Con Seam, EL se convirtió en la forma en que debería ser. Los métodos de llamada incluso con parámetros funcionan como una brisa.