Questions & Answers

[bit_mbrandt]

Hallo,

wir haben in unserem Template die Situation, dass sprachabhängig ein Feld einer Datenquelle auf der übergeordneten Seitenvorlage verwendet werden soll.

Da scheinbar im Falle von Datenquellen kein Zugriff auf die Editorfelder möglich ist (zumindest liefert bei

uns das folgende Konstrukt nur Werte für "normale" Absatzvorlagen:

$CMS_SET(lv_editornames, mySection.getFormData().getForm().appendEditorNames(null))$
$CMS_FOR(editorname, lv_editornames)$
     <name>$CMS_VALUE(editorname)$</name>
$CMS_END_FOR$

Deshalb nutzen wir für Datenquellen das folgende Konstrukt:

$CMS_SET(datasourcefield)$title_$CMS_VALUE(#global.language)$$CMS_END_SET$    
Plain: '$CMS_VALUE(datasourcefield)$'
Hardcoded: '$CMS_VALUE(#global.multiPageParams.data.get(0).getValue("title_DE"))$'
Dynamisch: '$CMS_VALUE(#global.multiPageParams.data.get(0).getValue(datasourcefield))$'

Die Variante Plain zeigt den Feldname korrekt an: "title_DE"

Die Variante Hardcoded liefert den korrekten Inhalt des Feldes "title_DE"

Die Variante Dynamisch bleibt leer. Sollte diese nicht auch den Inhalt liefern?

Gibt es eine Alternative, um das Feld sprachabhängig anzusteuern?

Danke und Grüße,

Martin Brandt

[feddersen · Accepted solution]

Wenn man das CMS_SET so anwendet, liefert das ein Template-Fragment zurück und nicht den ausgewerteten Ausdruck. Man kann aber ein .toString() aurufen, um die Auswertung zu erzwingen:

Dynamisch: '$CMS_VALUE(#global.multiPageParams.data.get(0).getValue(datasourcefield.toString))$'

Alternativ das CMS_SET so verwenden:

$CMS_SET(datasourcefield, "title_" + #global.language)$

[bit_mbrandt]

Vielen Dank Herr Feddersen,

die Lösung funktioniert. Ich hatte zwar das toString bereits getestet, aber dort aus Gewohnheit zwei Klammern zuviel gehabt, also: "datasourcefield.toString()" statt "datasourcefield.toString".

Vielen Dank und viele Grüße,

Martin Brandt