¿El atributo de forma taglib desactivada de primavera realmente tiene que resolverse en una cadena?

Question

He estado jugando con el taglib de forma de primavera últimamente y encontré un fenómeno bastante inquietante.

<form:select path="whatever" disabled="${true}"> 

rendirá un elemento de selección que no está deshabilitado

<form:select path="whatever" disabled="${'true'}"> 

rendirá un elemento de selección que está deshabilitado.

Esto me indica que la etiqueta espera una cadena en ese atributo y se niega a forzar cualquier valor booleano (posiblemente verificando primero el tipo).

El impacto es que no puedo hacer algo como <form:select path="whatever" disabled="${someOtherfield.selectedId != -1}" />, que es algo que sucede con bastante frecuencia en nuestro sistema.

¿Me falta simplemente alguna parte de la funcionalidad de taglibs de forma? ¿Es esta una decisión de diseño legítima? ¿Un defecto?

Answer 1

Ok, he hecho un poco más a excavar alrededor de éste, porque las soluciones temporales buscaban demasiado feo.

http://forum.springsource.org/showthread.php?t=84102

El problema era que el JSP estaba evaluando la EL, y comparando ciegamente el resultado de dicha evaluación utilizando "verdaderos" .equals

La comparación de una cadena a un valor booleano que utilicen este método siempre devolverá falso porque el tipo no coincide, por lo que definitivamente es un defecto.

Afortunadamente, el método isDisabled defectuoso es un trazador de líneas protegido, por lo que he podido solucionarlo extendiendo las 8 etiquetas de entrada efectuadas y reemplazando ese método para hacer una comparación un poco más sólida.

Así que la respuesta es, sí, es un defecto, y de los comentarios de skaffman parece que es un problema con una biblioteca antigua que no está muy bien actualizada ya que se implementó JSP EL.

Gracias por sus respuestas chicos

Answer 2

Esto es un poco extraño, lo suficiente. El código fuente de Spring muestra que la propiedad disabled de SelectTag es String, no boolean. Claramente, esto no es lo correcto, pero sospecho que sigue siendo así por razones heredadas (spring-form.tld es anterior a JSP EL).

Eso deja al tiempo de ejecución de JSP forzar un boolean en un String, y aparentemente no hará esto. Estoy menos sorprendido acerca de esto, ya que JSP EL es notoriamente limitado.

Así que está atrapado entre dos implementaciones semi-rotas. Solo deberá asegurarse de pasar los valores de cadena a ese atributo.

Answer 3

La causa de este diseño es que tienen un código de reserva especial para forzar la evaluación de la expresión EL cuando el contenedor no la evalúa. Por ejemplo, este código:

<%@ page isELIgnored = "true" %> 
... 
${'Simple text'} <spring:message text = "${'Message text'} />" 

produce ${'Simple text'} Message text

Probablemente, es útil para algunas configuraciones de contenedores legado extraños.

Es decir, el siguiente código no funcionaría si hacen disabled atributo boolean:

<%@ page isELIgnored = "true" %> 
... 
<form:select ... disabled = "${true}" />