1

MVC3 アプリで、ヘルパー (DropDownList) によって生成される HTML に name 属性を設定できるようにしたい状況があります。

これは不可能のようです。どうやら、ヘルパーは、ヘルパーに渡す html 属性オブジェクトの name 属性に指定できる値を暗黙のうちにオーバーライドします。

既存のヘルパーを使って作業することに時間を浪費する前に、それを確認したいと思います。

余談ですが、設計上それが不可能な場合...それは MVC フレームワークのばかげた制限だと思います。はい、間違った名前属性を割り当てると、自動モデル バインディングが壊れる可能性があることはわかっています。しかし、必要なときにそれを行うことができるはずです。結局のところ、選択した name 属性を使用して生の html をいつでも記述できます。ヘルパーは拘束具ではなく、助けるべきです。

編集して、エディター テンプレートがナビゲーション コンテキストを維持するかどうかを議論する

Darin、私はエディター テンプレートを使用しています (エディター テンプレートは特別な種類の部分ビューであるため、一般的に「部分」という用語を使用していました)。

エディター テンプレートはHtmlFieldPrefix を変更します。これが、私が問題に気付いた方法です :)。私はこのような呼び出しを使用していました:

// call in higher level partial - context is 'eae'
@Html.EditorFor(m => m.Value)
...
// inside editor template for typeof(Value) context is 'eae:Value'

このコンテキスト シフトは、既定のバインド メカニズムを適切に機能させるために必要です。私は別のアプローチを使用しています。ここでは、パーシャルの呼び出しチェーン全体でコンテキストを固定したままにします (つまり、実行がより深いパーシャルに潜り込むときに、コンテキストを同じままにしたい)。

4

1 に答える 1

1

これは仕様によるものです。nameHTML ヘルパーでは、属性をオーバーライドできません。ビュー モデルに基づいて名前が生成されるため、既定のモデル バインダーは、フォームが送信されたときに確立された規則に従って値を適切にバインドできます。

余談ですが、設計上それが不可能な場合...それは MVC フレームワークのばかげた制限だと思います。

MS Connect でチケットを開くことができ、これがフレームワークの将来のバージョンで変更されることを期待できます。それまでは、そのような機能が必要な場合に name 属性をオーバーライドできる独自のカスタム ヘルパーを作成することもできます。個人的には今のところ必要ありませんが、正当な理由があると確信しています。もう 1 つの可能性は、サーバー上にカスタム モデル バインダーを作成することです。

于 2012-05-10T16:36:39.753 に答える