EPiServer 7 - Dictionary-basierte benutzerdefinierte Eigenschaft Typ

Question

Ich habe auf EPiServer 7 MVC hochgefahren und durch Joel Abrahamssons Alloy MVC Template gegangen. Nachdem ich einen Blick auf den angepassten Preview Controller geworfen habe, der einen Block in 4 verschiedenen 'Größen' anzeigt, hatte ich die Idee, eine Eigenschaft zu erstellen, die spezifisch für eine bestimmte 'Blockgröße' ist, so dass der Überschriftentext z Beispiel könnte unterschiedliche Inhalte basierend auf der "Größe" anzeigen, die der Block rendert. Im Wesentlichen wäre dies ein Dictionary, in dem der Schlüssel die "Größe" und der Wert den String-Inhalt enthält.

Hat jemand solch eine Wörterbucheigenschaft gemacht?

Ich habe ein paar Ansätze ausprobiert und haben mit jedem stecken geblieben:

1. Benutzerdefinierte Objekttyp/custom Werttyp. Nach diesem Beispiel beim Erstellen von benutzerdefinierten Eigenschaftstypen (http://joelabrahamsson.com/creating-a-custom-episerver-property-with-a-custom-class-as-value/) habe ich einen benutzerdefinierten Eigenschaftstyp (PropertyDicitionaryString) und einen benutzerdefinierten Werttyp (DictionaryString) erstellt. Ich kann den Wert in Ordnung anzeigen, indem ich eine Anzeigevorlage implementiere, die ein Tag mit der Größe erhält und anschließend Model.MyDictionaryString [ViewData ["Tag"] als String darstellt). Ich habe jedoch nicht herausgefunden, wie die Inline-Bearbeitung funktioniert, da ein Aufruf von @ Html.EditAttributes (x => x.MyDictionaryString [ViewData ["Tag"] als String]) nicht unterstützt wird; Diese Methode unterstützt keine Index- oder Methodenaufrufe im Lambda-Ausdruck. Wer weiß, wie man einen solchen Inline-Editor erstellt?

2. Angepasster Eigenschaftstyp/primitiver Typ. Ich habe meinen benutzerdefinierten Eigenschaftstyp für oben überarbeitet, nennen wir ihn (PropertyDictionaryStringAsPrimitive), sodass die Value-Eigenschaft eine Zeichenfolge zurückgibt. Dies ermöglicht es mir mein Modell zu definieren, wie:

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

   ich in einer Art und Weise zu hacken hatte für die PropertyDictionaryStringAsPrimitive der ‚Größe‘ in dem aktuellen Wiedergabe-Kontext zu empfangen, wenn es Wert Methode ist hieß es, um sicherzustellen, kehrte die korrekter Wert. Ich konnte dies tun, indem ich einen benutzerdefinierten ContentDataInterceptor implementierte, der nach Aufrufen von PropertyDictionaryStringAsPrimitive.Value sucht und den Schlüssel entsprechend einstellt. So, jetzt den Wert anzeigen funktioniert gut, aber Inline-Bearbeitung funktioniert auch nicht ganz. Wenn der Ajax-Speicheraufruf ausgeführt wird, muss ich einige Statusinformationen hinzufügen, damit ich PropertyDictionaryStringAsPrimitive mitteilen kann, welcher Schlüssel zum Speichern der Änderungen verwendet werden soll. Wer weiß, wie man zusätzliche Statusinformationen während einer Inline-Edit-Ajax-Speicheranforderung zurückgibt?

3. Ich schaute auf das Attribut [CultureSpecific]. Es wäre interessant, wenn ich einen ähnlichen Mechanismus wie CultureSpecific verwenden könnte, um bestimmte Instanzen der Werte "Größe" beizubehalten. Nachdem ich einige Zeit in einem Decompiler verbracht habe, der versucht herauszufinden, wie hwo CultureSpecific seine Magie ausübt, habe ich das Attribut CotnentDataAttributeScanningAssigner.AssignValuesToPropertyDefinition verfolgt und das PropertyDefinitionModel.CultureSpecific-Flag auf true gesetzt, welches PropertyDefinitionSynchronizer.CreatePropertyDefintion benutzt, um das PropertyDefinitionModel.CultureSpecificValue auf ein Enum zu setzen. Aber ich konnte nicht herausfinden, wie diese Einstellung beeinflusst, welcher Wert geladen wird. Kann jemand ein Property-Level-Attribut verwenden, um den Wert dynamisch zu ändern? (In einem Inhaltsbereich oder Blöcke) (benötigt wo) und ein Block-Eigenschaft für die Eigenschaftswerte

Answer 1

ich in der Regel individuelle Immobilienarten vermeiden, ziehe ich das Festhalten an benutzerdefinierte Editoren.

Vielleicht ein gangbarer Weg wäre:

1) einen Bausteintyp wie SizeSpecificHeadingBlock erstellen mit:

1. A String-Eigenschaft Größe mit einem SelectOne Attribute für einen konfigurierten SelectionFactory Rückgabe der gültigen Größenbegrenzungsoptionen
2. Eine andere Zeichenfolge p roperty Heading für die eigentliche Überschrift Text

Als nächstes könnten Sie eine content mit Allowedtypes Set SizeSpecificHeadingBlock hinzuzufügen.

Beim Rendern der ContentArea wird einfach die Überschrift für die aktuelle Größe gerendert.

Dies würde jedoch erfordern Editoren, um einen Block pro Überschrift Variation zu erstellen, die ein bisschen umständlich ist - aber Sie könnten diesen Ansatz mit einem benutzerdefinierten Editor ergänzen, um den Prozess zu vereinfachen.

Die Verwendung einer systemeigenen Methode zum Speichern von Eigenschaftswerten (anstelle eines benutzerdefinierten Eigenschaftstyps) macht Ihre Implementierung zukunftssicher. Wenn Ihr benutzerdefinierter Editor jemals fehlschlagen sollte, können Sie ihn jederzeit deaktivieren und einfach die EPI-Server-Benutzeroberfläche "vanilla" verwenden, um Ihre Eigenschaftenwerte zu bearbeiten.

Edit: Obwohl derzeit in der Beta, könnte es relevant seinen Einsatz von Property <YourCustomType> für diese Art von Szenario zu machen, um zu vermeiden, verschachtelte Blöcke zu erstellen: http://world.episerver.com/blogs/Per-Magne-Skuseth/Dates/2015/11/trying-out-propertylistt/