Umstellung auf FS_LIST mit Type Database
Author: mmarm
Publication Date: 5/3/2013 10:41
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
-
Author: matthiasforberg - 6/17/2013 9:52
Naja, dann müssen wir uns wohl damit anfreunden, es so zu tun... Ich (oder wir) habe(n) ja auch grundsätzlich nichts dagegen, zukünftig data.ttName anstelle von data.name zu schreiben. Aber schade finde ich es schon, dass die Eingaben aller Fremdschlüssel "von beiden Enden" her angelegt werden müssen und importierte Felder als hidden mit angelegt werden müssen.
Die oben genannten Bedenken kann ich nachvollziehen und finde das alles auch berechtigt. Aber warum wird den dem Nutzer bzw. Entwickler nicht trotzdem die Möglichkeit gegeben, sich (auf eigene Gefahr) die Entity zu holen - falls eben FormData nicht ausreicht?
Gibt es denn mit FormData überhaupt die Möglichkeit, z.B. den letzten Bearbeiter oder das Freigabedatum oder ähnliches aus dem Datensatz auszulesen? Das sind ja Dinge, die automatisch gesetzt werden und bisher nicht über eine GUI angelegt wurden.
0 -
Author: boesebeck - 6/17/2013 15:06
Matthias Forberg wrote:
Gibt es denn mit FormData überhaupt die Möglichkeit, z.B. den letzten Bearbeiter oder das Freigabedatum oder ähnliches aus dem Datensatz auszulesen? Das sind ja Dinge, die automatisch gesetzt werden und bisher nicht über eine GUI angelegt wurden.
Der Punkt ist aktuell wirklich noch offen. Ich hab dazu intern ein Feature Request angelegt.
Ist dein Projekt aktuell davon betroffen, oder ist das erstmal ein theoretisches Problem?
Vielen Dank für den Hinweis
Gerrit
0 -
Author: matthiasforberg - 6/18/2013 9:23
Hallo Gerrit,
so akut ist es grad noch nicht, aber ich denke mir das ja nicht aus. Wir haben bestimmt 10 Projekte, wo solche Konstruktionen drin sind und die sollen in absehbarer Zeit alle migriert werden.
Nochwas:
Wie ist es denn mit den Fremdschlüsseln? Wir haben auch jede Menge Projekte, wo sich über Fremdschlüssel durch die Tabellen "gehangelt" wird. Konstrukte der Art #row.location.contacts.first.name sind keine Seltenheit bei uns.
Wenn nach der neuen Philosophie immer über die Formulare gegangen werden soll (was ich ja grundsätzlich nicht infrage stelle!), wie wird denn dann Folgendes gelöst:
- Es werden Datensätze per FS_LIST eingebunden
- 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
- aber hier kann ich es NUR so machen, denn wenn ich erstmal auf Entity bin, bekomme ich kein FormData mehr, um den letzten Schritt mit .csName auszulesen. Ich kann es also gar nicht anders machen als über .name. Oder sehe ich das falsch?
Grüße
Matthias
0 -
Author: boesebeck - 6/19/2013 14:20
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
0 -
Author: matthiasforberg - 6/20/2013 12:09
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
0 -
Author: StefanSchulz - 6/20/2013 12:27
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
0 -
Author: matthiasforberg - 6/21/2013 9:36
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
0 -
Author: LVanselow - 11/21/2013 13:53
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
0 -
Author: Peter_Jodeleit - 4/3/2014 13:23
Siehe auch Zugriff auf Entities in FS_LIST unter FirstSpirit 5 wieder ermöglichen.
0 -
Author: werlitz - 11/30/2015 17:38
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:
- 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())$ -
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.
0 - Entity über die ID laden:
-
Author: werlitz - 12/7/2015 13:09
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.
0 -
Author: mmarm - 5/3/2013 14:56
Hallo Jan,
vielen Dank für deine Antwort. Leider funktioniert genau das nicht mehr unter 5.0
Auch verstehe ich die Argumentation nicht ganz. Mich interessiert doch bei der Ausgabe nicht, welche Elemente für die Eingabekomponente erlaubt sind. Ob ich jetzt z.B. mit .Name (Spaltenname) oder .cs_name (Name Eingabekomponente) den Wert auslese, in der Weiterverarbeitung muss ich wissen was zurückkommt, oder ich mache es in beiden Fällen falsch.
Habe gerade nochmal in Mithras getestet und hier gibt es auch ein paar Beispiele bedingt durch die Fremdschlüsselbeziehung, für die ich noch extra Eingabekomponenten und Mappings anlegen müsste, nur um auf das Feld zugreifen und es ausgeben zu können, auch wenn ich z.B. von dieser Seite aus gar keine Pflege (erlauben) möchte (bzw. bei 1-n gar nicht bräuchte oder sogar durch Wahl einer Neuen eine bestehende Zuweisung löschen würde).
Zum Beispiel für eine Liste mit Produktkategorien, bei denen alle entsprechenden Produkte ausgegeben werden sollen, oder zu einem Medium die Galerien in denen es noch zu sehen ist, oder, oder, oder
Und das in einem so kleinen Projekt wie Mithras. Wird das Projekt komplex, steigt hier der Aufwand (nicht nur Migration, sondern auch Initialentwicklung) enorm an.
Wie bereits geschrieben, verstehe ich auch nicht den Grund, warum jetzt überhaupt komplett davon abgesehen wird über Spalten zu gehen. Hier würde mich eine Erklärung auch brennd interessieren!
Vielen Dank und viele Grüße
Matthias
0 -
Author: kohlbrecher - 5/3/2013 13:25
Hallo Matthias,
so viel ich weiß, sollte auch unter 5.0 noch folgendes funktionieren:
st_list.dataset.entity
Der Weg über die Eingabekomponente ist aber sauberer. Nur so kann sichergestellt werden, welche Elemente für die Eingabekompoente erlaubt sind, da dies nur aus der Definition im Formular klar wird.
Grüße
Jan
0 -
Author: matthiasforberg - 5/3/2013 15:41
Hallo zusammen,
ich habe es auch grad getestet und die o.g. Schreibweise
st_list.dataset.entityfunktioniert definitiv NICHT in der Version 5.0. Zumal die so sowieso nicht funktionieren würde, da man eine Schleife um st_list machen muss, so etwa:$CMS_FOR(item, st_list)$$CMS_VALUE(item.dataset.entity.name)$$CMS_END_FOR$Aber auch das funktioniert nicht, sondern nur so:
$CMS_FOR(item, st_list)$$CMS_VALUE(item.cs_name)$$CMS_END_FOR$Diese Umstellung halte ich aber auch für fragwürdig, denn Sinn und Zweck von Datenquellen ist es doch, auf Daten einer extern angebundenen Datenbank zugreifen zu können, und das sollte meiner Meinung nach unabhängig von Formulardefinitionen sein. Und die Argumentation, dass zukünftig alles über die Eingabekomponenten ausgelesen werden soll, kann ich überhaupt nicht nachvollziehen, zumindest nicht bei Datenquellen.
Ein Beispiel aus unserem Projektalltag:
Eine Datenquelle wird per Import aus einem Drittsystem mit Produktdaten befüllt. Die Datenbank hat z.B. 50 Felder für jedes Produkt, in FS werden aber nur die die relevanten 10-20 Felder angezeigt, die anderen interessieren für den redaktionellen Ablauf nicht - sollen aber trotzdem auf der HTML Seite ausgegeben werden.
An diese Daten kommt man jetzt nur dran, wenn man Dummy Eingaben mit hidden="yes" definiert. Das kann ja auch nicht die Lösung sein.
Was spricht denn dagegen, aus dem Rückgabewert von FS_LIST über eine Methode die Entities auslesen zu können? Das könnten wir bei der Migration relativ einfach anpassen ohne wirklich alles umbauen zu müssen.
Interessant finde ich auch, dass die drei Möglichkeiten, Datensätze zu verarbeiten so unterschiedlich funktionieren:
- Contentprojektion:
#rowgibt immer noch direkt die Entity aus - FS_DATASET gibt einen DatasetContainer zurück, wo man sich immerhin über
st_data.dataset.entitydie Entity rausholen kann - FS_LIST gibt ein IdentifiableIdProvidingFormData zurück, wo man nach meinen Erkenntnissen gar nicht mehr an die Entity dran kommt...
Ich plädiere für die Implementierung einer Methode getEntity() für die Klasse de.espirit.firstspirit.generate.IdentifiableIdProvidingFormData!
Grüße
Matthias
0 - Contentprojektion:
-
Author: mmarm - 6/13/2013 15:39
Für das Problem gibt es jetzt einen Feature Request, also gerne fleißig für eine Lösung voten:
Zugriff auf Entities in FS_LIST unter FirstSpirit 5 wieder ermöglichen.
0 -
Author: mmarm - 6/11/2013 14:00
Hallo nochmal,
es wäre toll, wenn es hier noch einen Kommentar von e-Spirit Seite geben würde, denn bei uns steht jetzt eine größere Migration an und es ist ja doch wesentlich aufwendiger auch noch sämtliche Eingabekomponenten der Datenquellen anpassen zu müssen (oder gar erst zu erstellen), um die Spalten auslesen zu können.
Auch eine Begründung, warum nicht könnte ja immerhin zu konstruktiven Diskussionen führen.
Vielen Dank und viele Grüße
Matthias
0 -
Author: Andreas-Knoor - 6/14/2013 16:23
Bei der Implementierung der FS_LIST wurde bewusst nur der Zugriff über das Formular (FormData) gewählt, da nur so eine korrekte Darstellung der Daten gewährleistet ist. Die Ausgabe der Daten über das Entity birgt viele Fallstricke, die ggf. zu einer fehlerhaften bzw. nicht validen Darstellung führen.
Hier ein paar Beispiele:
- Sprachabhängige Felder
- Ausgabe von FirstSpirit Editoren (DOM, FS_REFERENCE)
- Rückgriffwerte
- Konvertierungen
- Datenbank Abstraktion (Datenbankfeldnamen in Großbuchstaben/Kleinbuchstaben)
In der Tat gibt es aktuell noch Stellen die eine Entity zurück liefern, aber der Plan ist den Zugriff in Zukunft nur über das Formular (FormData) bereitzustellen.
Das empfohlene Vorgehen für die 5.0 Migration ist also:
- Formulardefinition für die bisher nicht hinterlegten Spalten anlegen
- Mapping für die neuen Felder anlegen
- Felder, die nicht gepflegt werden sollen, auf "hidden" setzen
- Template-Ausgabe anpassen
Mit diesem Vorgehen ist man (auch für die Zukunft) auf der sicheren Seite.
Sollte dieses empfohlene Vorgehen im Projekt zu größeren Problemen führen, könnt ihr mich gerne dazu persönlich konktieren, damit wir die einzelne Situation besprechen können.
Gruß,
Andreas
0
Vous devez vous connecter pour laisser un commentaire.
Commentaires
17 commentaires