Isolated vs Non-Isolated FS_LIST-Verwirrung
Author: hbarthel
Publication Date: 8/15/2018 11:03
Hallo zusammen,
wir haben hier grad festgestellt, dass man bei FS_LIST vom Typ database bei der Ausgabe der Listenelemente unterschiedliche Typen zurück bekommt (FS 2018-07):
In der isolated-Variante sind es EntityFormData (so war es bis 5.2R18 auch in non-isolated), wobei das beginnend mit R19 in der non-isolated-Geschmacksrichtung Objekte vom Typ IdentifiableIdProvidingFormData sind. Beides ist lt. Doku korrekt, weil sie beide IdProvidingFormData implementieren. Dennoch sind wir verwirrt. Kann das jemand erklären?
Ich muss evtl. nicht dazu sagen, dass die Vorgänger im Projekt hart kodiert auf EntityFormData prüfen und wir das jetzt korrigieren müssen :-(
Gruß, Heiko
-
Author: boersteken - 8/15/2018 15:55
Hallo Heiko,
warum an dieser Stelle nun Objekte einer anderen internen Klasse zurückkommen kann ich nicht sagen. Wie du aber richtig erkannt hast, hat sich das Verhalten der API nicht verändert. Das Problem entsteht dadurch, dass ihr Abhängigkeiten zu Klassen habt die nicht Teil der API sind. Davon raten wir stark ab, unter anderem um genau diese Situation die ihr jetzt habt zu vermeiden.
Daher ist meine Frage: Warum genau prüft ihr hart kodiert auf die Klasse EntityFormData und was ist eure fachliche Anforderung, die dies erzwingt?
Grüße,
Philipp
0 -
Author: hbarthel - 8/15/2018 21:41
Hallo Philipp,
das müssen wir noch herausfinden, wir haben den Code wie gesagt nicht geschrieben. Aber es beruhigt mich ungemein, dass e-Spirit selber nicht weiß, warum beim isolated und non-isolated jeweils Objekte unterschiedlichen Typs raus gegeben werden.
0 -
Author: gottschalk1 - 8/16/2018 9:40
Hallo Heiko,
um das Problem sinnvoll beurteilen zu können und einem etwaigen Problem auf die schliche zu kommen müsstest du uns mehr Informationen zur Verfügung stellen. Wo prüft Ihr auf die Klasse? im Ausgabekanal? in einem Script? in eurer eigenen Modulimplementierung?
Kannst du uns den Quellcode zwecks Reproduktion zur Verfügung stellen? Ich würde gerne ausschließen das Ihr gegen eine unserer internen Implementierungsklassen entwickelt.
Grüße aus Dortmund
Johannes
0 -
Author: hbarthel - 8/16/2018 9:50
Hallo Johannes,
das Mithras-Projekt nehmen und einmal im isolated und einmal im not-isolated FS:
- Brechpunkt in Vorlage "Products.job_categories" Zeile 13
- Seitenref "jobs_2" im Template Debugger laufen lassen
Die Variable _job hat dann jeweils verschiedenen Klassen: EntityFormData vs IdentifiableIdProvidingFormData.
Dass "wir", also unsere Vorgänger interne Klassen verwenden, habe ich ja jetzt schon zweimal geschrieben.
0 -
Author: mikula - 9/4/2018 15:21
Hallo Heiko,
ihr verwendet wie du bereits geschrieben hattest interne Klassen. Die Kollegen aus der Entwicklung des Kernproduktes versuchen bei Ihren Implementierungen immer API Kompatibel zu sein. Das bedeutet jedoch nicht, dass sie versuchen an allen Stellen die gleichen Interna zurückzugeben. Wie du selbst merken konntest, kann sich dies bei unterschiedlichen Betriebsformen durchaus unterscheiden.
Kurz: Bei der Entwicklung von Skripten oder Modulen, möglichst Immer versuchen API kompatibel zu bleiben.
In dem Konkreten Fall hieße dies: einfach nur mit "IdProvidingFormData" arbeiten.
Viele Grüße
Martin
0 -
Author: mbergmann - 9/5/2018 6:54
Hallo Heiko,
vielleicht als kleiner Tipp:
Ich vermute mal, dass ihr die internen Klassen im Rahmen einer "instanceof"-Prüfung nutzt. Das kann man genauso gut mit class("...").isCase(obj) machen - und da können dann auch Interfaces angegeben werden:
$CMS_IF(class("de.espirit.firstspirit.access.editor.fslist.IdProvidingFormData").isCase(someValue))$
Das entspricht einem
if(someValue instanceof IdProvidingFormData)
Viele Grüße
Michael
0
Vous devez vous connecter pour laisser un commentaire.
Commentaires
6 commentaires