Questions & Answers

[mmarm]

Hallo community,

nachdem wir hier jetzt wiederholt dieses Thema beim Entwickeln hatten noch einmal die Anfrage an die Community.

Das "Problem" ist, dass nach der Umstellung auf FS_LIST die Elemente nicht mehr als Entities, sondern als FormData zu Verfügung stehen.

So wie wir es sehen gibt es momentan als einzige "erlaubte" Möglichkeit nur die Bezeichner der Eingabekomponente um auf den Spalteninhalt zu kommen. Workaround über .getDataset().getEntity() geht zwar in 4.2, aber in 5.0 nicht mehr, da auch keine öffentliche API.

Das bedeutet, dass bei anstehenden Migrationen hier ein riesen Aufwand bei der Umstellung auf uns zukommt, da auch sämtliche Ausgaben angepasst werden müssen, die bisher direkt über die Spaltennamen funktioniert haben.

Wurde die Möglichkeit über Entities zu gehen aus einem bestimmten Grund entfernt?

Z.B. folgende Szenarien werden dadurch ungleich Aufwändiger:

• Fremdschlüsselbeziehungen die über die andere Tabelle(nvorlage) gepflegt werden
• Imports, die alle DB Felder befüllen, aber es sollen lange nicht alle dem Redakteur angezeigt werden
• ...

Das neue Verhalten erfordert jetzt das anlegen von Eingabekomponenten für alle Spalten, die man auslesen möchte, unabhängig davon, ob man diese auch in der Tabellenvorlage pflegt. Uns ist nicht ganz klar, wo hier jetzt der Vorteil gegenüber dem "alten" Verhalten liegt.

Wäre toll, wenn ihr uns aufklären könntet 🙂

Viele Grüße

Matthias

[boesebeck]

Matthias Forberg wrote:

Ich greife z.B. mit stList.first.location auf den Fremdschlüssel des ersten Datensatzes zu

jetzt habe ich wieder einen Typ Entity und kann mich nach o.g. Beispiel weiter hangeln: stList.first.location.contacts.first.name

Also wenn man nur über das FormData geht und auf die Fremdschlüsselbeziehung wieder über eine FS_LIST geht, dann bekommt man immer nur FormData.

Was ist den in deinem Fall location? Kannst du bitte dazu dein Formular an das Posting hängen.

Gerrit

[matthiasforberg]

Hallo,

okay, das war jetzt ein konstruiertes Beispiel und zugegebenermaßen nicht ganz korrekt (ich wollte es nicht zu kompliziert machen). Ich habe es aber nachbauen können (Version: 5.0.210):

Hier mein Datenmodell:

In company ist eine location über Radiobutton ausgewählt, in location je ein contact (auch Radiobutton).

Dann habe ich eine Absatzvorlage mit einer FS_LIST namens stList gemacht. Seite angelegt und einen Datensatz ausgewählt. Folgende Klassen bekomme ich zurück, wenn ich mich durch die Fremdschlüssel hangele:

Variable	Class
stList	de.espirit.firstspirit.generate.IdentifiableFormDataList
stList.first	de.espirit.firstspirit.generate.IdentifiableIdProvidingFormData
stList.first.ttLocations	de.espirit.firstspirit.store.access.contentstore.ContentOptionFactory$ContentOption
stList.first.ttLocations.value	de.espirit.or.impl.EntityImpl
stList.first.ttLocations.value.contacts	de.espirit.or.impl.EntityImpl
stList.first.ttLocations.value.contacts.name	java.lang.String

Das bedeutet, ab der 2. Fremdschlüssel-Ebene, also da wo ich tatsächlich die Location hole, geht es wie eh und je auf Entity weiter und ich kann gar nicht mehr über das Formular gehen.

Auch wenn das jetzt konstruiert klingen mag, solche Konstrukte haben wir tatsächlich in vielen Projekten, teilweise noch weitergehend über 3, 4, 5 Tabellen... Das ist zwar nicht schön, lässt sich aber nicht immer vermeiden.

Grüße

Matthias

[StefanSchulz]

Hi,

ein Radiobutton ist nicht formularbasiert sondern arbeitet hier mit der direkten Anbindung einer Tabelle mittels Fremdschlüssel. Es gibt von der Komponente aus keine Möglichkeit, das Ziel auf ein Formular abzubilden. FormData ist ja auch wesentlich jünger als Options-basierte Komponenten, daher auch nicht wirklich verwunderlich.

Wenn es um eine einzige Verbindung geht, und eine Combobox als Alternative zum Radiobutton in Frage kommt, ist FS_DATASET eventuell eine gute Wahl. Hierüber kommt man auch an ein entsprechendes FormData des referenzierten Datensatzes.

Beste Grüße

Stefan

[matthiasforberg]

Ah okay, Danke für die Erklärung, wieder was gelernt. Jetzt habe ich natürlich aus reiner Neugier das Ganze umgebaut und FS_DATASET für meine Auswahl für location und contact verwendet. Der Vollständigkeit halber liste ich auch wieder die ganzen Zwischenergebnisse tabellarisch auf:

Variable	Class
stList	de.espirit.firstspirit.generate.IdentifiableFormDataList
stList.first	de.espirit.firstspirit.generate.IdentifiableIdProvidingFormData
stList.first.ttLocation	de.espirit.firstspirit.client.access.editor.DatasetEditorValueImpl$DatasetContainerImpl
stList.first.ttLocation.dataset	de.espirit.firstspirit.store.access.contentstore.DatasetImpl
stList.first.ttLocation.dataset.formData	de.espirit.firstspirit.access.store.contentstore.gom.list.EntityFormData
stList.first.ttLocation.dataset.formData.ttContact	de.espirit.firstspirit.client.access.editor.DatasetEditorValueImpl$DatasetContainerImpl
stList.first.ttLocation.dataset.formData.ttContact.dataset	de.espirit.firstspirit.store.access.contentstore.DatasetImpl
stList.first.ttLocation.dataset.formData.ttContact.dataset.formData	de.espirit.firstspirit.access.store.contentstore.gom.list.EntityFormData
stList.first.ttLocation.dataset.formData.ttContact.dataset.formData.ttName	java.lang.String
stList.first.ttLocation.dataset.entity.contacts.name	java.lang.String = selbes Ergebnis, aber kürzer!

so brauche ich ein paar Zwischenschritte mehr, aber ich gehe immer über das Formular (die Eingabekomponenten sind immer die mit dem Präfix tt). Finde ich zwar umständlicher, aber es funktioniert auch.

In der letzten Zeile habe ich noch eine Variante, wie ich trotzdem von FS_DATASET wieder auf die Entity komme und m.E. leichter an den Fremdschlüssel. Ist diese Schreibweise denn generell verpönt oder gelten die Warnhinweise (siehe oben, Andreas Knoor) speziell für die komplexen Datentypen (DOM, Reference etc.)?

Das mit den Sprachabhängigen Feldern kann ich noch nicht ganz nachvollziehen. Bisher war es doch so, dass sich FS automatisch das richtige Feld holt. Wenn ich z.B. #row.name schreibe, wird auf deutsch #row.name_DE ausgelesen und auf englisch #row.name_EN. Oder gilt das in V5.0 nicht mehr?

Grüße

Matthias

[LVanselow]

Hallo zusammen,

leider gab es noch keine Aussage zu diesem Thema im Zusammenspiel mit der aktuellen FirstSpirit Version 4.2.497.59222.

In dieser gibt es eine Vermischung von IdentifiableFormDataList (Preview) und FormDataList (Generierung). Bug/Feature?

Darüber, dass man von nun an direkt auf die Eingabefelder des FormData Objekts zugreift, lässt sich (zumindestens bei einfachen Datentypen wie Boolean, String, Integer etc.) streiten.

In vielen Fällen ist einfach praktischer direkt auf die Entities zuzugreifen.

Wir haben dies nun über eine Formatvorlage gelöst, die mittels QUERY die entsprechenden Entities direkt aus dem Schema holt und sortiert.

VG

Lars

[Peter_Jodeleit]

Siehe auch Zugriff auf Entities in FS_LIST unter FirstSpirit 5 wieder ermöglichen.

[werlitz]

Ich frage mich an dieser Stelle, warum eigentlich jede Eingabe-Komponente, die mit Datensätzen arbeitet, einen anderen Weg bietet, um auf die Daten des Datensatzes zuzugreifen. Das ist nicht konsistent und erschwert die Vereinheitlichung von Template-Code, wenn an verschiedenen Stellen unterschiedliche Eingabe-Komponenten verwendet werden müssen.

Um auf die Entity eines FS_LIST-Eintrags vom Typ "database" zuzugreifen gibt es noch diese Wege:

1. Entity über die ID laden:
   $CMS_SET(userService, #global.project.getUserService())$
   $CMS_SET(Type, class("de.espirit.firstspirit.access.store.Store$Type"))$
   $CMS_SET(contentStore, userService.getStore(Type.CONTENTSTORE, false))$
   $CMS_SET(cs, contentStore.getContent2ByName("news") )$
   $CMS_SET(dataSet, cs.getDataset(item))$
   $CMS_SET(entity, dataSet.getEntity())$
2. Aus der FormData "extrahieren":
   $CMS_SET(entity, class("de.espirit.firstspirit.access.store.contentstore.gom.list.EntityFormDataAccessor").new.getEntity(item))
   Nicht public API, aber löst das lästige Problem.

[werlitz]

Ach ja, falls man bei der zweiten Variante eine FS_LIST in Seiten bzw. Absatztemplates einsetzt muss man abweichend zur FS_LIST in einem Datenquellen-Template folgende Zeile verwenden:

$CMS_SET(entity, class("de.espirit.firstspirit.access.store.contentstore.gom.list.EntityFormDataAccessor").new.getEntity(item.value))

da hier die ausgewählten Datensätze in der FS_LIST noch in Objekten vom Typ de.espirit.firstspirit.generate.IdentifiableIdProvidingFormData gewappt werden.