Search the FirstSpirit Knowledge Base
Hallo,
ich benötige ein Methode, die mir das table template eines DatasetContainer liefert analog zu getDefaultContentNode.
Mein alter Code sah so aus:
DatasetEditorValue editor = ...
String templateName = editor.getDefaultContentNode().getName();
Mein Neuer Ansatz ist dieser:
DatasetContainer datasetContainer = (DatasetContainer) formField.get();
Dataset dataset = datasetContainer.getDataset();
String templateName = dataset.getTableTemplate().getName();
Allerdings ist schon dataset an dieser Stelle null.
Wie komme ich an das TableTemplate?
Ok, die Nutzung von FormFields deutet bei Templates auf die Auswertung der Default-Werte hin, ist das so richtig? Über diesen Weg sehe ich aktuell keine Möglichkeit, an die gewünschte Informationen heranzukommen. Es wäre aus fachlicher Sicht auch der falsche Ansatz, denn hier arbeitet man auf einer Instanz des Gadgets, die ja nicht alle Varianten der erlaubten Konfiguration wiederspiegelt.
Alternativ könnte man über die Formulardefinition gehen (Template#getGomProvider()#forms()) und die GomDataset Instanzen auswerten. Das ist dort zwar vieles keine API, hat sich aber seit einigen Versionen fachlich nicht verändert. Möglicherweise lohnt sich eine Feature-Anfrage, um hierüber einen zukunftssicheren Weg für das Auswerten der Formulardefinitionsobjekte zu schaffen.
Beste Grüße
Stefan
Hallo Michael,
du kannst mit datasetContainer.isEmpty prüfen, ob ein DataSet vorhanden ist.
Versuch mal datasetContainer.getTemplateUid() und dann einfach TableTemplate tableTemplate = (TableTemplate) templateStore.getStoreElement(<uid>, TableTemplate.UID_TYPE);
Viele Grüße
Thorsten
Erst mal schönen Dank
datasetContainer.isEmpty() liefert in diesem Falle wirklich true und templateUid ist null, aber das ist auch immer so, da wir ja Content in ein leeres FS-Projekt importieren.
Ich benötige aber gerade auch für leere Datasets den templateNamen. Die alte Logik (sieh oben) liefert das auch, aber die ist ja deprecated.
Hi,
die Anfrage ist ein wenig verwirrend. Die Methode getDefaultContentNode()
liefert (wie der Name schon sagt) kein TableTemplate sondern ein Content2-Element. Wenn der Name zufällig einer Tabellenvorlage entspricht, mag der (unbekannte) Code, der diesen nutzt, funktionieren. Generell jedoch ist es der falsche Name.
Dass ein leerer Datensatz kein Template hat, sollte einleuchten, denn ohne eine Auswahl ist auch keine Vorlage bekannt.
Obige Methode liefert auch nicht den aktuell zum Datensatz gehörenden Knoten, sondern den Knoten der ersten im GOM definierten, erlaubten Quelle (SOURCES-Tag). Das passt entsprechend nur dann zusammen, wenn lediglich ein Knoten erlaubt ist. Dies wäre wohl auch der einzige Weg, um an dessen Namen zu kommen. Auch wenn sich das GOM des Dataset-Gadgets nicht in der API ist.
Am Besten wäre, wenn der Kontext (also, von wo wird versucht auf den Templatenamen zuzugreifen) und Anwendungsfall (wofür wird der Name benötigt) hier beschrieben werden, um über eine Lösung nachzudenken.
Beste Grüße
Stefan
Der Code ist dafür da, demjenigen, der über unsere Anwendung Daten in FirstSpirit Importieren möchte, die Information zu übermitteln, welche Daten in dieser Eingabekomponente erlaubt sind.
z.B. für ein FS_DATASET
Und in welchem Kontext wird dieser Code ausgeführt? Über welchen Pfad gelangt man im Code an besagten DatasetContainer?
Es wird über die Templates Iteriert und dann über alle einzelnen EingabeKomponenten des Templates. Ist formField.getType() ein DatasetContainer, so werden halt die Infos dazu generiert. Unter anderm halt auch das gültige TableTemplate als Info.
Ok, die Nutzung von FormFields deutet bei Templates auf die Auswertung der Default-Werte hin, ist das so richtig? Über diesen Weg sehe ich aktuell keine Möglichkeit, an die gewünschte Informationen heranzukommen. Es wäre aus fachlicher Sicht auch der falsche Ansatz, denn hier arbeitet man auf einer Instanz des Gadgets, die ja nicht alle Varianten der erlaubten Konfiguration wiederspiegelt.
Alternativ könnte man über die Formulardefinition gehen (Template#getGomProvider()#forms()) und die GomDataset Instanzen auswerten. Das ist dort zwar vieles keine API, hat sich aber seit einigen Versionen fachlich nicht verändert. Möglicherweise lohnt sich eine Feature-Anfrage, um hierüber einen zukunftssicheren Weg für das Auswerten der Formulardefinitionsobjekte zu schaffen.
Beste Grüße
Stefan