Questions & Answers

[jan_bogutzki]

Hallo Community,

wir haben aktuell unseren ContentCreator auf die TPP umgestellt und die Applikation wird bereits angezeigt. Wenn ich aktuell in der Suche einen Treffer aus einer CMS-Seite erhalten, wird ein Event getriggert den unsere Applikation fängt und die entsprechenden Daten dafür aus einem Baum sucht. Finde ich nun aber einen Datenbanktreffer, dann wird dieses Event nicht geworfen und wir können nicht auf den Klick des Redakteurs reagieren. Gibt es eine Möglichkeit, dass der Event für diese Suchtreffer ebenfalls ausgelöst wird?

beste Grüße

Jan Bogutzki         

[cthomas]

Hi Jan, dieser Event sollte natürlich auch bei Datenbanktreffern ausgelöst werden. Wir schauen uns das mal genau an.

[jan_bogutzki]

Hallo Christian,

In FS5 2018-10 scheint es nun zu funktionieren. Ich erhalten zumindest einen Event und die gesuchte previewId. Ich erweitere nun gerade unseren ID-Baum um das fertig zu tetsen.

Update:

Aktuell erstellen wir die PreviewId für einen Datenbankeintrag in Verknüpfung mit einer speziellen Seite. Dies führt dann z.B. zu folgender previewId:

eyJkYXRhLWZzLWF0dHJzIjoiZXlKc1lXNW5kV0ZuWlVGaVluSmxkbWxoZEdsdmJpSTZJa1JGWDBSRklpd2lkR1Z0Y0d4aGRHVkpaQ0k2T0RNMU5URTRmUT09IiwiZGF0YS1mcy1pZCI6ImV5SnpZMmhsYldFaU9pSkNiRzluY3lJc0ltVnVkR2wwZVZSNWNHVWlPaUppYkc5bklpd2laVzUwYVhSNVNXUWlPamd6T0RZc0ltbGtJam93TENKemRHOXlaU0k2SWtOUFRsUkZUbFJUVkU5U1JTSjkifQ==

Wenn ich in der Suche auf ein Element klicke, dann erhalte ich dort aber folgende ID:

eyJkYXRhLWZzLWF0dHJzIjoiZXlKc1lXNW5kV0ZuWlVGaVluSmxkbWxoZEdsdmJpSTZJa1JGWDBSRkluMD0iLCJkYXRhLWZzLWlkIjoiZXlKbGJuUnBkSGxKWkNJNk9ETXlNQ3dpYVdRaU9qZzJPVE00Tml3aWMzUnZjbVVpT2lKVFNWUkZVMVJQVWtVaWZRPT0ifQ==

Die Information zur Seite ist also mindestens nicht enthalten. Da wir 2 Blogs in der gleichen Datenbank haben, haben wir folglich auch 2 getrennte Detailseiten. Wie kann ich das der Suche beibringen, dass die richtige PreviewId generiert/verwendet wird?

Gruß

Jan

[cthomas]

Hi Jan,

wie genau wird die erste PreviewId erzeugt? Also was wird in der PreviewId Funktion $CMS_VALUE(previewId( ??? ))$ angegeben und in welchem Template-Typ?

Die zweite PreviewId zeigt (analog zum ContentCreator) auf die Detailseite, die in der Tabellenvorlage als Vorschauseite hinterlegt ist.

Wir arbeiten derzeit an einem neuen Format für die PreviewIds, womit in Zukunft hier sicherlich eine Erleichterung erreicht wird.

Ist ein CaaS im Einsatz?

Gruß

Christian

[jan_bogutzki]

Hallo Christian,

die ID wird wie folgt erstellt:

$CMS_SET(set_template,"Blogs.blog_1")$ // je nach Marke, kann da auch ein anderer Name stehen

$CMS_VALUE(previewId(element:ref(template:set_template).getDataset(blogItem)).toJSON(),default:"")$

Diesen Weg hatte mir Peter in einem anderen Thread empfohlen. Die Seiten an sich scheinen in der 2. PreviewId zu stimmen, es matched durch das Template leider nicht.

CaaS verwenden wir aktuell nicht.

[cthomas]

Hi Jan,

kannst du es mal mit

$CMS_VALUE(previewId(element:<BlogDetail-PageRef>, entity:blogItem))$

versuchen?

[jan_bogutzki]

Hallo Christian,

mit der Seitenreferenz hat es geklappt, aber:

wir haben aktuell 2 Datenbankschemata (basieren beide auf der gleichen Tabelle), eines für jede Marke. Aktuell wird aber nur eins der beiden verwendet und daher kommt auch das durcheinander bei den Seiten. Es sah soweit mal gut aus, mal nicht. Es werden aktuell alle Blogbeiträge durch das gleiche Datenbankschemata in der Suchergebnisliste gerendert. Das heißt für die zweite Marke stimmt die Detailseite dann leider nicht. Das führt dann dazu, dass die Detailansicht für die zweite Marke nicht funktioniert, da der Filter für die Seite den gewählten Beitrag nicht zulässt. Die PreviewId aus den Suchergebnissen ist folglich nicht richtig für die eigentliche Detailseite.

Kann man das irgendwie beeinflussen?

Gruß

Jan

[Peter_Jodeleit]

Hallo Jan,

entschuldige die späte Rückmeldung hier, irgendwie ist dein letzter Post bei uns leider untergegangen. Ist das Thema noch aktuell oder habt ihr schon eine Lösung dafür gefunden?

Eventuell könnt ihr im callback von TPP_API.Common.addPreviewRequestHandler​ auf den Fall reagieren?

Gruß, Peter

[jan_bogutzki]

Hallo Peter,

ja, es ist noch aktuell. Ich habe bisher keine Stelle/Funktion gefunden, die mir das richtig/sauber generiert.

Problem ist aktuell weiterhin, dass die Seite von der ersten Datenbankvorlage genommen wird (auch wenn dort der Filter gar nicht greift). Die Seite funktionier bei uns dann nur bei der Hälfte der Beiträge.

In der Theorie könnten wir in der addPreviewRequestHandler drauf reagieren, aber wir müssten dann auch entsprechend alles doppelt generieren, einmal mit der falschen und einmal mit der richtigen ID, das wäre auch sehr unschön. Gerade weil unser gesamter Seitenbaum bereits mehrere Sekunden braucht fürs Generieren. Da ist der initiale Load schon sehr aufwändig.

Gruß

Jan

[Peter_Jodeleit]

Hallo Jan,

das Verhalten ist eine Einschränkung des ContentCreators: Für die Pflege wird eine Seite benötigt, welche alle Datensätze anzeigen kann. Dies muss die Vorschauseite der Tabellen-Vorlage sein (die Seite muss aber nicht unbedingt über die Navigation erreichbar sein).

Im TPP hat man aber an der Stelle noch eine Chance einzugreifen. Dazu könnt ihr euch im Callback für Navigations-Änderungen die Daten zu dem Element holen (über Operation.renderElement) und dann abhängig von den Daten zur passenden URL eurer App navigieren. Ich gehe davon aus, das die Marke auch in den Daten steht? Diese müsste dann "nur" an der entsprechenden Stelle in die URL injiziert werden..

War das verständlich?

Gruß, Peter