Does spring form taglib disabled attribute really have to resolve to a string?

Question

I've been playing around with the spring form taglib lately and came across a fairly disturbing phenomenon.

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

Will render a select element that is NOT disabled

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

Will render a select element that IS disabled.

This indicates to me that the tag expects a string in that attribute and is refusing to coerce any boolean values (possibly checking the type first).

The impact is that I'm unable to do something like <form:select path="whatever" disabled="${someOtherfield.selectedId != -1}" /> which is something that happens fairly often in our system.

Am I simply missing some part of the form taglibs functionality? Is this a legitimate design decision? A defect?

Answer 1

This is a bit odd, right enough. The Spring source code shows that the disabled property of SelectTag is String, not boolean. This is clearly not the right thing to do, but I suspect it's still that way for legacy reasons (spring-form.tld pre-dates JSP EL).

That leaves it up to the JSP runtime to coerce a boolean into a String, and apparently it won't do this. I'm less surprised about this, since JSP EL is notoriously limited.

So you're caught between two semi-broken implementations. You'll just need to make sure you pass String values to that attribute.

Answer 2

The cause of this design is that they have a special fallback code to force EL expression evaluation when container doesn't evaluate it. For example, this code:

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

produces ${'Simple text'} Message text

Probably, it's useful for some strange legacy container configurations.

That is, the following code wouldn't work if they make disabled attribute boolean:

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

Answer 3

Ok, I did some more digging around this one, because the work-arounds were looking too ugly.

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

The problem was that the JSP was evaluating the el, and blindly comparing the result of that evaluation using "true".equals

Comparing a String to a Boolean using that method will always return false because the type's don't match so it's definitely a defect.

Fortunately the isDisabled method at fault is a protected one liner, so I have been able to work around it by extending the 8 input tag's effected and overriding that method to do a slightly more robust comparison.

So the answer is, yes, it is a defect, and from skaffman's comments it looks like it's a bit of a problem with an old library not being very well updated as JSP EL was implemented.

Thanks for your answers guys