Questions & Answers

[MichaelN]

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

[andre]

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() | ...]

[MichaelN]

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)

[MichaelN]

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

[StefanSchulz]

Moin,

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

Gruß

Stefan

[MichaelN]

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
 ...
}

[StefanSchulz]

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?

[MichaelN]

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

[StefanSchulz]

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?

[MichaelN]

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.

[StefanSchulz]

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