Auslesen der EntityFormData Editoren aus dem ContentStore

Zendesk API User

January 07, 2014 12:47

Author: MichaelN
Publication Date: 1/7/2014 12:47

Hallo,

ich möchte über die Editoren der Eingabekomponenten eines Datasets (content.getDataset(entity);) iterieren.

dazu hole ich mir das FormData

FormData formData = dataProvider.getFormData();

und dann den entsprechenden Editor:

formData.getForm().findEditor(editorName).getDefaultValue();

genau hier ist mein Problem.

Als Test lese ich die Datenbank-Schemata-Vorlagen des Mithras-Projekts aus.

Bei z.B. "Produkte" (product_categories) erhalte beim Aufruf von getDefaultValue() den Wert null und ich komme logischerweise nicht an die Informationen dieses Editors (z.B. für 'cs_name' der TextEditorValue)

Bei z.B. "Produktvorschläge" (product_offers) erhalte ich den TextEditorValue mittels 'cs_name' und alles ist gut

Related to

Comments

20 comments

Zendesk API User

January 07, 2014 13:07
Author: andre - 1/7/2014 13:07

formData = Dataset#getFormData()

d.h. dann

final FormField<?> formField = formData.get(language, editorName);

formField.get() <= dieses ist den der Wert des editors.

formData.getForm() greift auf die Formulardefinition zu. und wenn kein default-wert gesetzt ist wird null geliefert.
0
Zendesk API User

January 08, 2014 09:35
Author: aVogt - 1/8/2014 9:35

vielleicht hilft das ja:

final List<String> listVarNam = formData.getForm().appendEditorNames(null);

Da brauchst Du nicht die namen der Eingebekomponenten wissen. Du bekommst eine Liste mit allen Namen der Eingabekomponenten zurück.
0
Zendesk API User

January 08, 2014 12:15
Author: MichaelN - 1/8/2014 12:15

Ja mittels formField.get() komme ich dann an den Wert des editors, aber ich benötige ja ein EditorValue<?> um dann dynmaisch auf die einzelnen unterschiedlichen Editoren zu reagieren.
Das funktioniert auch überall wunderbar nur bei einigen Datenbank-Schemata-Vorlagen halt nicht.
Aber es existieren hier alle EditorValues:
0
Zendesk API User

January 08, 2014 12:29
Author: andre - 1/8/2014 12:29

Michael Nahberger wrote:

Ja mittels formField.get() komme ich dann an den Wert des editors, aber ich benötige ja ein EditorValue<?> um dann dynmaisch auf die einzelnen unterschiedlichen Editoren zu reagieren.

was heisst denn in deinem fall dynamisch? mir ist nicht klar warum du die EditorValue brauchst?

willst du abhaengig von einem Wert einen anderen ändern? ...da könnten die Regeln/Ruls helfen. willst du nur den Typ des Werts wissen... -> de.espirit.firstspirit.forms.FormField#getType
0
Zendesk API User

January 08, 2014 12:50
Author: MichaelN - 1/8/2014 12:50

Wir haben hier eine Anwendung, die das importieren von Daten in FS erlaubt.Hierfür lesen wir im Vorhinein die Informationen aus FS aus um möglichst nur validen Content zu importieren.

z.B. benötigen wir im Falle, dass es sich um ein OptionsEditorValue handelt das OptionModel, welches wir mittels getOptionModel ermitteln. dazu müssen wir aber wissen, dass es sich um ein OptionsEditorValue handelt.
0
Zendesk API User

January 08, 2014 13:12
Author: andre - 1/8/2014 13:12

((OptionFactoryProvider)form.findEditor(formField)).getOptionFactory();

und ueber die Factory kommt man an das OptionModel. und getType von FormField sollte in diesem FAll Option.class sein
0

Zendesk API User

January 08, 2014 13:21

Author: MichaelN - 1/8/2014 13:21

OK und für _alle_ anderen Eingabekomponenten geht das analog?

Wir stellen gerade Code auf die FormData-Api um und der alte sieht etwa so aus und wir konnetne immer mit dem EditorValue arbeiten und auf dieser Grundlage agieren:

Data d = ...
                              
DataValue dv = d.get(varName);
EditorValue<?> editorValue = dv.getEditor();
if (editorValue instanceof ComboboxEditorValue) {
  // do something
} else if (editorValue instanceof ContentAreaListValue) {
  // do something
} else if (editorValue instanceof ...){
...

Das geht so dann wohl nicht mehr!?

Zendesk API User

January 08, 2014 13:28
Author: andre - 1/8/2014 13:28

> Das geht so dann wohl nicht mehr!?

.... FormField#getType liefert keine EditorValue aber den WerteTyp.

ComboboxEditorValue ...siehe oben Option

ContentAreaListValue siehe API -> interface ContentAreaListValue extends EditorValue<SectionList>

also ist der WerteTyp SectionList

usw.
0
Zendesk API User

January 08, 2014 14:44
Author: MichaelN - 1/8/2014 14:44

Hoffentlich letzte Frage :smileyhappy::

Wie komme ich dann an die Methoden des ehemals gelieferten GomEditorProvider:

getAllowEmpty, convertEntities, usesLanguages etc.
0
Zendesk API User

January 08, 2014 14:54
Author: andre - 1/8/2014 14:54

http://www.e-spirit.com/odfs50/access/de/espirit/firstspirit/forms/FormData.html

siehe api: de.espirit.firstspirit.forms.FormData#getForm liefert einen GomEditorProvider

name = de.espirit.firstspirit.forms.FormField#getName

FormData.getForm().findEditor(name).[allowsEmpty() | ...]
0

Zendesk API User

January 09, 2014 07:35

Author: MichaelN - 1/9/2014 7:35

Ich versuche das gerade umzusetzen stoße aber schon wieder auf ein Problem.

Wenn ich über die options iteriere fliegt _nur_ bei Produkteigenschaften (product_properties => cs_property (CMS_INPUT_COMBOBOX))

OptionFactory optionFactory = ((OptionFactoryProvider) editor).getOptionFactory();
OptionModel optionModel = optionFactory.getOptionModel(broker, lang, false);
for (Option option : optionModel) { <- hier fliegt die Exception

die folgende Exception:

java.lang.IllegalStateException: No specialist found for 'de.espirit.firstspirit.agency.StoreAgent$1@9f3c6a19'!

at de.espirit.firstspirit.agency.AbstractSpecialistsBroker.requireSpecialist(AbstractSpecialistsBroker.java:14)

at de.espirit.firstspirit.store.access.contentstore.ContentOptionModel.getTableTemplateInternal(ContentOptionModel.java:94)

at de.espirit.firstspirit.store.access.contentstore.ContentOptionModel.getEntityType(ContentOptionModel.java:78)

at de.espirit.firstspirit.store.access.contentstore.ContentOptionModel.createList(ContentOptionModel.java:195)

at de.espirit.firstspirit.store.access.contentstore.ContentOptionModel.getList(ContentOptionModel.java:182)

at de.espirit.firstspirit.store.access.contentstore.ContentOptionModel$OptionIterator.<init>(ContentOptionModel.java:284)

at de.espirit.firstspirit.store.access.contentstore.ContentOptionModel.iterator(ContentOptionModel.java:275)

Zendesk API User

January 15, 2014 07:34
Author: MichaelN - 1/15/2014 7:34

Hat hier jemand eine Idee, warum ich nicht die Datensätze product_properties auslesen kann?
0
Zendesk API User

January 15, 2014 09:28
Author: StefanSchulz - 1/15/2014 9:28

Moin,

woher kommt denn der SpecialistsBroker broker, der dort übergeben wird? In welchem Kontext wird der Code ausgeführt?

Gruß

Stefan
0

Zendesk API User

January 15, 2014 11:01

Author: MichaelN - 1/15/2014 11:01

Hallo,

der Broker commt von Connection.getBroker().

Der Code sieht in etwa so aus:

GomEditorProvider form = formData.getForm();
GomFormElement editor = form.findEditor(varName);        
OptionFactory optionFactory = ((OptionFactoryProvider) editor).getOptionFactory();
OptionModel optionModel = optionFactory.getOptionModel(broker, lang, false);
for (Option option : optionModel) { <- hier fliegt die Exception
 ...
}

Zendesk API User

January 15, 2014 11:22
Author: StefanSchulz - 1/15/2014 11:22

Ja, die Connection ist der falsche Lieferant. Der Broker einer Connection hat keinerlei Projektinformationen und kann somit auch nicht auf den Store zugreifen.

Wie wird die Routine denn gestartet? Über Kontextmenü? Über Menü? Serverseitig? Ist es ein Skript? Eine Klasse? Ein Service?
0
Zendesk API User

January 15, 2014 11:26
Author: MichaelN - 1/15/2014 11:26

Es ist eine eigenständige Anwendung, welche die API nutzt und mittels Dieser eine Connection aufbaut (ConnectionManager.getConnection).
0
Zendesk API User

January 15, 2014 11:35
Author: StefanSchulz - 1/15/2014 11:35

Ah. Ok. Aber irgendwie wird doch auch auf die Daten des Projekts zugegriffen. Und da geht es anscheinend nicht über den Broker der Connection, oder?
0
Zendesk API User

January 15, 2014 11:42
Author: MichaelN - 1/15/2014 11:42

Hmmm, welche Daten? Alle? auch die Seiten, oder nur die Datensätze?

Die Templates z.B. werden so geholt
```
project = connection.getProjectByName(name);
templateStore = (TemplateStoreRoot) project.getUserService().getStore(Type.TEMPLATESTORE, false);
```
Also anscheinend immer vieles über den UserService.
0
Zendesk API User

January 15, 2014 11:49
Author: StefanSchulz - 1/15/2014 11:49

Das habe ich mir schon so gedacht. Mit der Nutzung von UserService und Broker wird alte und neue API gemischt. Jetzt kann man konsequent weiter die alte API nutzen, dann nutzt man den UserService auch, um sich das OptionModel zu holen (als veraltet markierte Methode). Oder man holt sich den Projekt-bezogenen Broker über connection.getBroker().requireSpecialist(BrokerAgent.TYPE).getBrokerByProjectName(name). Dann könnte man darüber auch auf die Stores zugreifen.

Vielleicht solltet ihr über eine Konsolidierung der API-Nutzung nachdenken. Eine Mischung ist nicht unbedingt zukunftsfähig.

Gruß

Stefan
0
Zendesk API User

January 15, 2014 12:13
Author: StefanSchulz - 1/15/2014 12:13

Das wird aktuell auch nicht gehen, weil es für einige Zugriffe (noch) keine Alternativen gibt. Mit Vermischung meine ich, dass z. B. der TemplateStore über den UserService geholt wird, die inneren Daten (OptionModel) dann mit Hilfe eines Brokers. Würde man sich den TemplateStore über einen Broker holen (Projekt-bezogen, wie oben, über den StoreAgent), wäre auch der Zugriffsweg auf die OptionFactory klarer ersichtlich. Der SpecialistsBroker ersetzt benötigte API aus Connection, Project und UserService durch die modulare Bereitstellung von spezialisierten und funktional übersichtlichere Agenten. Hier ist ein einheitlicher Weg vermutlich sinnvoller, als Teile zu ersetzen.

Ich hoffe, dass jetzt ein funktionierender Weg für Euer Problem an dieser Stelle gefunden wurde.

Gruß

Stefan
0

Please sign in to leave a comment.

Comments

Didn't find what you were looking for?