Muss das feder forml taglib disabled Attribut wirklich in eine Zeichenkette aufgelöst werden?

Question

Ich habe in letzter Zeit mit der Feder Form Taglib gespielt und stieß auf ein ziemlich beunruhigendes Phänomen.

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

Wird ein ausgewähltes Element machen, die NICHT

deaktiviert

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

Wird ein ausgewähltes Element machen, das deaktiviert wird.

Das bedeutet für mich, dass das Tag eine Zeichenfolge in diesem Attribut erwartet und es ablehnt, alle booleschen Werte zu erzwingen (möglicherweise zuerst den Typ zu überprüfen).

Die Auswirkung ist, dass ich etwas wie <form:select path="whatever" disabled="${someOtherfield.selectedId != -1}" /> nicht tun kann, was ziemlich häufig in unserem System passiert.

Fehle ich einfach einen Teil der Taglibs-Funktionalität des Formulars? Ist das eine legitime Designentscheidung? Ein Defekt?

Answer 1

Ok, habe ich einige mehr zu graben, um dieses eine, weil die Umgehungen wurden zu hässlich suchen.

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

Das Problem war, dass die JSP den el evaluierte und blind das Ergebnis dieser Auswertung Vergleich mit „true“ .equals

Vergleicht man einen String in einen booleschen mit dieser Methode wird immer Rückkehr falsch, weil die Typen nicht übereinstimmen, also ist es definitiv ein Defekt.

Glücklicherweise ist die isDisabled-Methode, die fehlerhaft ist, eine geschützte Einlage, also konnte ich sie umgehen, indem ich die acht Eingabemarken ausführte und diese Methode überschrieb, um einen etwas robusteren Vergleich durchzuführen.

Also die Antwort ist, ja, es ist ein Defekt, und aus skaffmans Kommentaren sieht es so aus, als sei es ein kleines Problem mit einer alten Bibliothek, die nicht sehr gut aktualisiert wird, da JSP EL implementiert wurde.

Vielen Dank für Ihre Antworten Jungs

Answer 2

Das ist ein bisschen seltsam, richtig genug. Der Spring-Quellcode zeigt, dass die disabled-Eigenschaft von SelectTagString ist, nicht boolean. Dies ist eindeutig nicht das Richtige, aber ich vermute, dass es aus Legacy-Gründen immer noch so ist (spring-form.tld pre-dates JSP EL).

Das überlässt es der JSP-Laufzeit, ein boolean in ein String zu zwingen, und anscheinend wird es dies nicht tun. Ich bin weniger überrascht, da JSP EL notorisch begrenzt ist.

Sie sind also zwischen zwei Semi-Broken-Implementierungen gefangen. Sie müssen nur sicherstellen, dass Sie String-Werte an dieses Attribut übergeben.

Answer 3

Die Ursache dieses Designs ist, dass sie einen speziellen Fallback-Code haben, um die Auswertung des EL-Ausdrucks zu erzwingen, wenn der Container sie nicht auswertet. Zum Beispiel dieser Code:

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

produziert ${'Simple text'} Message text

Wahrscheinlich, es ist nützlich für einige seltsame Legacy-Container-Konfigurationen.

Das heißt, würde der folgende Code nicht funktionieren, wenn sie disabled Attribut boolean machen:

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