Questions & Answers

[dehaatbi]

Hallo,

ich würde gerne mit einem Skript eine DOM Table anlegen. Es gibt ja das Interface 

de.espirit.firstspirit.access.editor.value.Table

leider liegt die zugehörige Implementierung TableImpl nicht in der fs-isolated-runtime und kann daher mit dem isolated mode nicht mehr ohne weiteres benutzt werden.

Gibt es eine andere Möglichkeit eine Instanz einer Tabelle zu erstellen mittels Java-Code? Die Tabelle scheint das einzige Input Element zu sein, welches sich nicht ohne weiteres per Code manipulieren lässt. Ist das Absicht oder müssen vielleicht einfach die Klassen in die fs-isolated-runtime in Zukunft?

Gruß Tobi

[hbarthel]

Bis 2025.1 ging das noch, seit 2025.2 ist TableImpl aus der so genannten API verschwunden und ich würde auch gern wissen, wie man das jetzt macht.

[Windmüller]

Die FirstSpirit-Access-API unterliegt strengen Anforderungen an die Kompatibilität, die eine Verwendung über viele Releases von FirstSpirit erlaubt.

Die Klasse TableImpl war jedoch nie Teil dieser API. In der API-Dokumentation ist sie nicht erwähnt und seit Release 2022.11 ist sie explizit mit "ApiStatus.Internal" markiert. Je nach IDE wird eine Verwendung der Klasse direkt mit einer Warnung quittiert. Solche Klassen sollten nicht verwendet werden, da sie sich jederzeit ohne Vorwarnung ändern können oder sie wie in diesem Fall nicht mehr zugänglich sein können.

Das Interface Table beschreibt im JavaDoc, dass es sich um die Persistenz-Klasse des DomTableEditorValue handelt. Über die Methode get(Language) lässt sich hier eine entsprechende Table holen, das Erzeugen sollte nicht notwendig sein.

Dabei ist zu beachten, dass DomTableEditorValue spätestens seit Release 2023.03 als "deprecated" gilt. Der Zugriff über FormData bzw. FormField liefert immer eine Table-Instanz für den Editor zurück, die Verwendung des EditorValue ist nicht notwendig.

[hbarthel]

Heißt das, dass das hier beschriebene Problem gelöst ist?

https://community.crownpeak.com/t5/Questions-Answers/Problem-beim-einf%C3%BCgen-von-Inhalten-in-DOMT...

[dehaatbi]

---

@Windmüller wrote:

Das Interface Table beschreibt im JavaDoc, dass es sich um die Persistenz-Klasse des DomTableEditorValue handelt. Über die Methode get(Language) lässt sich hier eine entsprechende Table holen, das Erzeugen sollte nicht notwendig sein.

---

In meinem konkreten Anwendungsfall manipuliere ich das zugrundeliegende XML der Tabelle. Ich wüsste nicht wie ich das ohne die TableImpl bewerkstelligen soll. Bei der TableImpl konnte man ja einfach XML in den Konstruktor geben. Auch das verlinkte Problem von @hbarthel scheint ja darauf zu basieren, dass man XML verarbeitet.

Für andere Eingabekomponenten gibt es ja auch die entsprechenden Implementierungsklassen in der fs-isolated-runtime. Daher verstehe ich nicht wieso das bei TableImpl anders gemacht wird.

[Windmüller]

---

@hbarthel wrote:

Heißt das, dass das hier beschriebene Problem gelöst ist?

---

Der Entwickler hat sich leider dafür entschieden, einen undokumentierten Weg zu nutzen. In unserer internen Bug-Datenbank konnte ich keinen Feature-Request zu dem Thema finden. Daher wird auch dieser Weg mit neueren Versionen nicht mehr funktionieren.

Daher noch einmal die Bitte: Klassen, Methoden und Felder, die mit "ApiStatus.Internal" versehen sind, sollten nicht verwendet werden. Wenn die Warnung in der IDE nicht ausreicht, kann ArchUnit helfen, solche Verwendungen einfach aufzudecken. Im Falle fehlender Funktionalität ist ein entsprechendes Support-Ticket immer die bessere Wahl.

[Windmüller]

---

@dehaatbi wrote:
In meinem konkreten Anwendungsfall manipuliere ich das zugrundeliegende XML der Tabelle. Ich wüsste nicht wie ich das ohne die TableImpl bewerkstelligen soll. Bei der TableImpl konnte man ja einfach XML in den Konstruktor geben. Auch das verlinkte Problem von @hbarthel scheint ja darauf zu basieren, dass man XML verarbeitet.

Beschreibst Du bitte einmal den konkreten Anwendungsfall, also warum genau Du das XML manipulieren musst?

Für andere Eingabekomponenten gibt es ja auch die entsprechenden Implementierungsklassen in der fs-isolated-runtime. Daher verstehe ich nicht wieso das bei TableImpl anders gemacht wird.

---

Wenn diese anderen Klassen (wie z.B. OptionImpl) ebenfalls mit "ApiStatus.Internal" annotiert sind, sollten sie so behandelt werden, als wären sie gar nicht vorhanden. Denn auch wenn sie nicht direkt verschwinden, kann sich die interne Struktur ohne Vorwarnung ändern, da für diese die Stabilitätskriterien der Access-API nicht gelten.

[dehaatbi]

Im konkreten Fall jetzt geht es um eine maschinelle Übersetzung. Man ließt also einmal das XML aus, jagt es durch die Übersetzungs-API und erzeugt daraus dann eine neue Table. Ich frage mich in diesem Zusammenhang auch wie ein Modul wie Translation Studio funktionieren kann, ohne Zugriff auf das darunterliegende XML.

Mir ist das mit den internen APIs prinzipiell schon klar, dass man diese nicht verwenden soll, aber oft braucht man halt eine schnelle Lösung und dann wird das eben schnell mal billigend in Kauf genommen, dass es irgendwann wieder bricht.

[Windmüller]

---

@dehaatbi wrote:

Im konkreten Fall jetzt geht es um eine maschinelle Übersetzung. Man ließt also einmal das XML aus, jagt es durch die Übersetzungs-API und erzeugt daraus dann eine neue Table.

Ein Teamkollege wies mich gerade auf einen möglichen Workaround hin. Und zwar könnte es funktionieren, die Tabelle in ein LANG-Tag zu wrappen:

<LANG><TABLE ...></LANG>

Dies übergibt man dann an das FormField in Form eines Element.

Aber: Auch wenn dieser Weg funktioniert und er keine internen Klassen verwendet, handelt es sich immer noch um einen undokumentierten Workaround. Erstelle bei Bedarf daher bitte einen entsprechenden Feature-Request, gerne mit Verweis auf diesen Thread.

[hbarthel]

Das ist ein guter Tipp, habe ich ausprobiert und funktioniert. Da muss man erstmal drauf kommen, dass man die table beim set in ein LANG-Element stopfen muss 🙂