3

私は JSF RI 1.1_02 で立ち往生しており、この問題が発生しています。

私が期待しているFaceletコードは次のとおりです。

<h:form>
    <h:selectOneMenu value="#{bean.num}" converter="javax.faces.Integer">
        <f:selectItem itemLabel="one"   itemValue="1" />
        <f:selectItem itemLabel="two"   itemValue="2" />
        <f:selectItem itemLabel="three" itemValue="3" />
    </h:selectOneMenu>
    <h:commandButton value="submit" />
    <h:messages />
</h:form>

リクエスト スコープ Bean:

public class Bean {
    private int num;

    public void setNum(Integer aNum) {
        num = aNum;
    }

    public Integer getNum() {
        return num;
    }
}

Validation Error: Value is not validを受け取りました。コンバーターを必要としないコードをほとんど書いていないのに、何が間違っているのか想像できません。明らかな何かが欠けているのでしょうか、それとも JSF RI 1.1_02 のバグですか?

バッキング Bean のプロパティ タイプを に変更するだけで問題を回避できますがString、(自動) 変換が必要なときにそうしなければならないことに不満を感じています。

4

1 に答える 1

7

時間をかけて JSF RI 1.1_02 プレイグラウンド環境を作成したところ、問題を再現できました。ソースコードを確認した後、犯人は、<f:selectItem>値が送信された値と同じ型に変換されていないようです。したがって、基本的にはアイテムStringの値を送信された値と比較してIntegerおり、この比較は決して返されませんtrue。

これは非常に厄介なバグであり、技術的にはUISelectOneコンポーネントを交換することによってのみ解決できます (UISelectManyちなみに、同じバグが公開されています)。問題はプライベートmatchValue()メソッドにあります。<f:selectItem>カスタムコンバーター（私が最初に考えていたソリューション）は、値に対してまったく呼び出されないため、まったく役に立ちません。

Mojarra 1.2_15にアップグレードすると、問題は即座に修正されました。

更新: 本当に、本当に、アップグレードできない場合に備えて、EL 強制を利用した回避策を見つけました: 静的文字列の代わりに EL で値を参照すると、それらは暗黙的に として扱われLongます。プロパティ タイプを から に変更するIntegerとLong、コンバーターなしで機能します。

<h:selectOneMenu value="#{bean.num}">
    <f:selectItem itemLabel="one"   itemValue="#{1}" />
    <f:selectItem itemLabel="two"   itemValue="#{2}" />
    <f:selectItem itemLabel="three" itemValue="#{3}" />
</h:selectOneMenu>

と

private Long num;
于 2012-07-30T20:00:52.803 に答える