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

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