6

私は EPiServer 7 MVC を強化しており、Joel Abrahamsson のAlloy MVC Templateを試しました。ブロックをレンダリング可能な 4 つの異なる「サイズ」でプレビューする、カスタマイズされたプレビュー コントローラーを調べた後、特定のブロックの「サイズ」に固有のプロパティを作成して、見出しテキストをたとえば、ブロックがレンダリングする「サイズ」に基づいて異なるコンテンツを表示できます。基本的に、これはキーが「サイズ」で値が文字列の内容を含むディクショナリになります。

誰かがそのような Dictionary プロパティを作成しましたか?

私はいくつかのアプローチを試しましたが、それぞれに行き詰まりました：

  1. カスタム プロパティ タイプ / カスタム値タイプ。カスタム プロパティ タイプの作成に関するこの例 ( http://joelabrahamsson.com/creating-a-custom-episerver-property-with-a-custom-class-as-value/ ) に従って、カスタム プロパティ タイプ (PropertyDicitionaryString) を作成しました。 ) およびカスタム値の型 (DictionaryString)。サイズのタグを受け取り、Model.MyDictionaryString[ViewData["Tag"] as string] をレンダリングする表示テンプレートを実装することで、値をうまく表示できます。ただし、 @Html.EditAttributes(x => x.MyDictionaryString[ViewData["Tag"] as string]) への呼び出しがサポートされていないため、インライン編集を機能させる方法を理解していません。そのメソッドは、ラムダ式でのインデックス呼び出しまたはメソッド呼び出しをサポートしていません)。 このようなインライン エディタの作成方法を知っている人はいますか?

  2. カスタム プロパティ タイプ / プリミティブ タイプ。上記のカスタム プロパティ タイプを作り直しました。これを (PropertyDictionaryStringAsPrimitive) と呼び、Value プロパティが文字列を返すようにします。これにより、モデルを次のように定義できます。

    [BackingType(typeof(PropertyDictionaryStringAsPrimitive)] public virtual string SizeSpecificString{get;set;}

    Value メソッドが呼び出されたときに PropertyDictionaryStringAsPrimitive が現在のレンダリング コンテキストで「サイズ」を受け取り、正しい値が返されるようにする方法でハックする必要がありました。これは、PropertyDictionaryStringAsPrimitive.Value への呼び出しを探して Key を適切に設定するカスタム ContentDataInterceptor を実装することで実現できました。したがって、値の表示は正常に機能するようになりましたが、インライン編集もまったく機能しません。ajax 保存呼び出しが行われるとき、変更を保存するためにどのキーを使用するかを PropertyDictionaryStringAsPrimitive に伝えることができるように、いくつかの状態情報を追加する必要があります。 インライン編集 ajax 保存リクエスト中に追加の状態情報を返す方法を知っている人はいますか?

  3. [CultureSpecific]属性を見てみました。値の「サイズ」固有のインスタンスを保持するために、CultureSpecific と同様のメカニズムを使用できれば興味深いでしょう。CultureSpecific がどのように機能するかを逆コンパイラで調べた後、CotnentDataAttributeScanningAssigner.AssignValuesToPropertyDefinition が PropertyDefinitionModel.CultureSpecific フラグを true に設定するまでの属性を追跡しました。しかし、この設定が読み込まれる値にどのように影響するかはわかりませんでした。 プロパティレベルの属性を使用して値を動的に変更する方法を知っている人はいますか?

4

1 に答える 1

3

私は通常、カスタム プロパティ タイプを避けます。カスタム エディター (必要な場合) と、プロパティ値のブロック プロパティ (またはコンテンツ領域のブロック) に固執することを好みます。

おそらく実行可能なアプローチは次のとおりです。

1) SizeSpecificHeadingBlockのようなブロック タイプを作成します。

  1. 有効なサイズ境界オプションを返す、SelectionFactory用に構成されたSelectOne属性を持つSizeという名前の文字列プロパティ
  2. 別の文字列プロパティHeading実際の見出しテキスト

次に、 AllowedTypesがSizeSpecificHeadingBlockに設定されたContentAreaを追加できます。

ContentArea をレンダリングするときは、現在のサイズの見出しを単純にレンダリングします。

ただし、これには編集者が見出しのバリエーションごとに 1 つのブロックを作成する必要があり、これは少し面倒ですが、カスタム エディターを使用してこのアプローチを補完し、プロセスを簡素化することができます。

(カスタム プロパティ タイプの代わりに) ネイティブな方法でプロパティ値を格納すると、実装の将来性が高まります。また、カスタム エディターが失敗した場合は、いつでも無効にして、"普通の" EPiServer UI を使用してプロパティ値を編集できます。

編集:現在ベータ版ですが、ネストされたブロックを作成する必要がないように、この種のシナリオではPropertyList<YourCustomType>を使用することが適切な場合があります: http://world.episerver.com/blogs/Per-Magne-Skuseth /日付/2015/11/お試し物件リスト/

于 2015-04-08T18:21:39.457 に答える