Questions & Answers

[andreas_schaedl]

Hallo Community,

ich habe folgende Situation: Ich baue gerade eine Umfrage und möchte sowohl Fragen wie auch Antworten einzigartige IDs mitgeben.

Derzeit habe ich ein Sectiontemplate "Survey", darin ein FS_CATALOG mit dem eine Liste von Sectiontemplates "Question" eingebunden wird und in denen wiederum ein FS_CATALOG mit dem eine Liste von Sectiontemplates "Answer" eingebunden wird. Die Auslese erfolgt dann jeweils über CMS_FOR

Nun hätte ich gerne für alle drei Elemente unique IDs, die ich dann in der Applikation und Persistierung verwenden kann. Für die SurveyID ist das kein Problem, mit #global.section.id oder #this.id bekomme ich diese. Das Gleiche funktioniert aber mit Sectiontemplates, die über FS_CATALOG verknüpft werden, nicht. Wenn ich mich recht entsinne, ging das doch mit FS_LIST?

Ich kann jetzt zwar mittels einer Kombination aus SurveyID und #for.index einzigartige IDs erzeugen, aber sobald der Redakteur die Reihenfolge der Fragen oder Antworten verändert, ändern sich ja auch die IDs.

Gibt es keine elegante Möglichkeit das zu lösen? Haben die Catalog Cards wirklich keine IDs? Übersehe ich etwas offensichtliches?

Danke und viele Grüße,

Andreas

// Obligatorische FS Infos:

FirstSpirit SiteArchitect 5.2.515.74918

[mbergmann · Accepted solution]

Hallo Andreas,

das sollte sich folgendermaßen lösen lassen - ist zwar eher ein Workaround, dafür aber recht simpel:

Definiere in den inneren Templates ein zusätzliches CMS_INPUT_DATE mit preset="created" und verstecke es per Regel. Dadurch wird es automatisch immer mit dem aktuellen Zeitstempel versehen und kann auch nicht geändert werden. Der Zeitstempel ist dabei immer der beim Hinzufügen des Elementes in den FS_CATALOG.

Im Ausgabekanal nutzt Du dann als eindeutige ID z.B. den Hashcode oder auch die Millisekunden:

$CMS_VALUE(st_date.hashCode)$ oder

$CMS_VALUE(st_date.getTimeInMillis())$

Viele Grüße

Michael

[andreas_schaedl]

Hallo Michael,

vielen Dank für deine Antwort. Das ist tatsächlich eine recht geschickte Lösung. Ein Problem sehe ich hier aber:

Kopiere ich jetzt eine der Umfragen  und füge sie woanders wieder ein, haben alle Fragen und Antworten die gleiche ID (gleiches Erstellungsdatum)

Wir haben noch etwas tiefer gegraben und die Methode getIdentifiers() gefunden. (an der Stelle nochmal vielen Dank an mhenke​)

Im Sectiontemplate einer Frage ergibt sich dann für:

$CMS_VALUE(#this.getIdentifiers())$ <br>

$-- #this.class = de.espirit.firstspirit.generate.IdentifiableCatalogCard$IdentifiableCatalogCardItem --$

$CMS_FOR(answer,st_answers)$

     $-- answer.class = de.espirit.firstspirit.generate.IdentifiableCatalogCard --$

     $CMS_VALUE(answer.getIdentifiers())$ <br>

$CMS_END_FOR$

Der folgende Output:

[st_questions, c3b21191-9f53-455f-b587-17205e3938ad]

[st_questions, c3b21191-9f53-455f-b587-17205e3938ad, st_answers, 6e0cb9b2-5ec1-46f0-bf3c-82adda693168]

[st_questions, c3b21191-9f53-455f-b587-17205e3938ad, st_answers, 0c95592b-bd69-4fcd-9b40-ac034210759b]

[st_questions, c3b21191-9f53-455f-b587-17205e3938ad, st_answers, 6bf0a543-49d8-4b49-9464-7f84ed50a5ba]

Somit erhält man für jedes Element eine UUID, sogar inklusive Eltern-Element (Im Fall der Antworten). Spricht etwas gegen dieses Vorgehen? Gibt es einen Grund, warum diese Methode nicht in der Dokumentation auftaucht? (oder habe ich sie nur übersehen?)

Danke und viele Grüße,

Andreas

[mbergmann]

Hallo Andreas,

gegen die Verwendung von getIdentifiers() spricht, dass sie nicht in der API bzw. Doku steht und es sich somit um interne Implementierungsdetails handelt, die theoretisch jederzeit geändert werden können. Also würde ich eher davon abraten. Ich hatte vorher tatsächlich selber nach so etwas geschaut 😉

Zu deinem "Kopierproblem": Hier könntest Du einfach als "finalen" Identifier die Kombination aus der ID des Absatzes / Datensatzes (also des enthaltenden Elementes, je nachdem was es bei Dir ist) und der "Zeitstempel-ID" nutzen.

Viele Grüße

Michael

[andreas_schaedl]

Hallo Michael,

dann werde ich es mit dem Zeitstempel lösen. Vielen Danke für deine Hilfe!

Grüße,

Andreas

[mbergmann]

Hallo Andreas,

gerne! Grundsätzlich finde ich Deinen Anwendungsfall jetzt zwar nicht alltäglich aber trotzdem auch nicht total exotisch.

Von daher wäre hier bestimmt ein Feature Request unter „Ideen“ (am besten mit Verweis auf diesen Thread) sinnvoll - intern sind ja „Identifier-taugliche“ Daten anscheinend vorhanden. Es geht ja nur darum, diese Daten (oder etwas daraus abgeleitetes „eindeutiges“) per API auf CATALOG-Elementen zugreifbar zu machen, so dass solche Workarounds nicht mehr nötig sind.

Viele Grüße

Michael