Llamar a un método con el parámetro de rizo interior JSTL

Question

tengo un JSP que necesita para imprimir algún texto que se produce tomando iterador bucle y dársela a otro objeto (frijol de primavera), algo así como:

<c:forEach var="myVar" items="${myVars}"> 
    <c:out value="anotherObject.getFoo(myVar)"/> 
</c:forEach> 

Obviamente el código anterior no es válido ya que el operador JSTL . solo permite invocaciones sin parámetros. Veo siguientes soluciones al problema:

1) Scriptlets

<c:forEach var="myVar" items="${myVars}"> 
    <% 
    SomeType myVar = (SomeType) pageContext.getAttribute("myVar"); 
    SomeOtherType anotherObject = (SomeOtherType) pageContext.getAttribute("anotherObject"); 
    YetAnotherType result = anotherObject.getFoo(myVar); 
    pageContext.setAttribute("result", result); 
    %> 
    <c:out value="${result}"/> 
</c:forEach> 

El aire aquí es obvia JSP código de la contaminación y la fealdad general.

2) Escribiendo una etiqueta que hace lo que sea que se haga dentro de scriptlets. Ejemplo típico de sobre-ingeniería, ¡puaj!

3) descomponer una colección de myVars y reemplazar cada myVar con un dynamic proxy, InvocationHandler de lo que añadiría método sin parámetros extra para hacer que todas las llamadas a través getFoo()anotherObject. Todo eso se haría en el controlador para que JSP permanezca limpio y myVar se mantenga igual. ¿Pero a qué precio?

No puedo agregar .getFoo() método al myVar porque no encaja allí y rompería la separación de las preocupaciones.

Parece que los parámetros de aprobación serán posibles en JSP/EL 2.2, pero estoy usando Tomcat 6.0.29, que solo incluye el EL 2.1 API.

Pregunta: ¿Alguien puede sugerir el enfoque más limpio para esta situación?

Answer 1

Así es como lo he hecho al final.

En lugar de pasar una colección de instancias SomeType, estoy pasando un mapa. Las claves del mapa son las mismas SomeType sy los valores son instancias de la clase interna específica del controlador, llamémoslo SomeTypeSupplement.

SomeTypeSupplement agrega los captadores necesarios sin arg y conecta todo junto. JSP ahora itera sobre las entradas del mapa y puede recuperar los datos a través de JSTL.

De esta manera evito Proxy TLDs mágicos e innecesarios, mantengo las JSP ordenadas y razonablemente seguras.

Answer 2

Si no puede cumplir con scriptlets (su alternativa 1), crearía una etiqueta personalizada para ella (su alternativa 2) o una función EL personalizada. No estoy de acuerdo en que sea una "sobre-ingeniería", es usar las herramientas disponibles para su propósito previsto.

Su alternativa 3, sin embargo, no me gusta. En todo caso, ESO está sobre-ingeniería y hará que su sistema sea innecesariamente complejo y más difícil de seguir para otras personas. Cumpla con las intenciones de las especificaciones y estándares en los que está trabajando. No hagas las cosas más difíciles o más complejas por el simple hecho de hacerlo.

Answer 3

¿Por qué no simplemente compones tu lista de objetos en tu código back-end Java y luego usas JSP para mostrarla?

Answer 4

Otra opción es usar Velocity. Es mucho mejor que jstl.

Answer 5

Un simple de Java sólo "truco-fix" que funciona en la versión más antigua JSTL, también, y no requiere Taglibs/config/Dependencias/marcos adicionales, etc. es de "envolver" la función que desea llame desde JSTL en una clase que se extiende desde una clase Map y anule su método get().

Como un ejemplo mínimo, si p. desee llamar a la función Math.sin() de JSTL, debe definir una clase:

public class Sine extends HashMap<Double, Double> { 
    private static final long serialVersionUID = 1L; // Avoids compiler-warning 

    @Override 
    public Double get(Object arg) { 
     Double x = (Double) arg; 
     return Math.sin(x); 
    } 
} 

Luego, en su acción método execute(), que hace:

... 
request.setAttribute("sine", new Sine()); 
... 

Luego, en JSP se puede decir:

${sine[0.75]} 

para calcular el valor Math.sin(0.75)

JSTL tratará el seno variable como Map, pero puede calcular y devolver todo lo que quiera del método get().

supongo que se hace un poco más complicado si usted tiene más de un argumento a su función, pero no debe haber soluciones para que, también :)

Answer 6

quería añadir un comentario a la última (por el tiempo) respuesta de Rop, pero falta "reputación", así que aquí estoy con una respuesta.

En breve tuve la misma idea con un mapa de este tipo, pero traté de hacerlo más general utilizable, con una "DynamicMap", interfaz DynamicMapCalculator y que permite ajustar cualquier llamada a dicho mapa (sin la necesidad de hacer un nueva implementación de mapas todo el tiempo, solo usando instanciación de clase anónima).

Este sería el tema, si está interesado: A qu. of style: dynamic map JSTL hack to work around missing parameter function calls

y yo estaría interesado en las opiniones allí: esto es algo que puede prescindir de una mala conciencia?