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

[kohlbrecher]

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

[mmarm]

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

[matthiasforberg]

Hallo zusammen,

ich habe es auch grad getestet und die o.g. Schreibweise st_list.dataset.entity funktioniert 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:

1. Contentprojektion: #row gibt immer noch direkt die Entity aus
2. FS_DATASET gibt einen DatasetContainer zurück, wo man sich immerhin über st_data.dataset.entity die Entity rausholen kann
3. 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

[mmarm]

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

[mmarm]

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.

[Andreas-Knoor]

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:

1. Formulardefinition für die bisher nicht hinterlegten Spalten anlegen
2. Mapping für die neuen Felder anlegen
3. Felder, die nicht gepflegt werden sollen, auf "hidden" setzen
4. 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

[matthiasforberg]

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.

[boesebeck]

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

[matthiasforberg]

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