Questions & Answers

[robert_wieser]

Hallo Community,

ich habe ein Problem beim Speichern komplexer Datentypen im Conent2-Bereich.

Beim Zurückspeichern sind die veränderten Spalten leer.

Kann mir bitte jemand sagen, wie man schreibend korrekt auf XML-Strukturen (Editoren sind:DomEditorValueImpl oder LinkListEditorValueImpl) zurgreifen kann.

(Die Editoren bekomme ich mit:   EditorValue<?> editorValue = editorWrapper.getAccessEditor(view.getStore().getProject().getUserService(), true);)

Hier der Auszug meines Codes:

Session session = view.getSchema().getSession();

// entity hohlen

Object valueObject = entity.getValue("Name");

if (valueObject instanceof EditorWrapper) {

     org.w3c.dom.Element node = editorWrapper.getData();

     // veränderen des XML-Objects

     EditorWrapper newEditorWrapper = new EditorWrapper(node);

     entity.setValue(column, newEditorWrapper);

}

session.commit();

session.release(entity);

session.commit();

Vielen Dank im Vorraus für eure Hilfe

Robert Wieser

[tklein]

Hallo,

das Thema "per Access-Api" Datensätze bearbeiten wurde in der Community schon an mehreren stellen beantwortet.

Auch bei Entitys sollte über das Data bzw. Dataset gearbeitet werden. Siehe dazu:

http://www.e-spirit.com/odfs42/access/de/espirit/firstspirit/access/store/contentstore/class-use/Dat...

[robert_wieser]

Hallo,

danke erst mal für die Unterstützung

Leider hift mir der Weg über DataSet nicht weiter.

Derzeit abeite ich an einem Modul, bei dem die Uid der Linktemplates verändert werden. Da bei Standard-Getttern das XML geparst komme ich um den Parsing-Error nicht herum.

Benennt man zuerst die Uid's um, erzeugt man bereits beim ersten Hohlen des Data-Objekts einen Error. Im anderen Fall halt beim Hohlen nach der Umbenennung.

Unsere derzeitige Lösung bei Seiten ist das Data-Objekt zu speichern, anschließend zu nullen, Uid umbenennen, gespeichertes Objekt korrigieren und schließlich zu setzten.

Jedoch funktioniert das nullen des (Entity-)Data-Objekts nicht, so dass dieser Weg ausgeschlossen werden muss.

Ein möglichst direkte, nicht gewrappter Zugriff könnte die Lösung sein.

Viele Grüße

Robert Wieser

[tklein]

Robert Wieser schrieb:

Leider hift mir der Weg über DataSet nicht weiter.

warum nicht? Denn dann kommt man an das Data / FormData Objekt. Von da aus dann an die EditorValues bzw. FormFields und somit auch an gesetze Links.

Dadurch benutzt man dann keinen keinen EditorWrapper, der im übrigen auch nicht Access-Api Bestandteil ist.

Über welche FirstSpirit Version reden wir? Und wie sieht der Anwendungsfall konkret aus?

[robert_wieser]

Hallo,

sorry, dass ich erst Heute antworten kann, wir haben gestern noch länger versucht das Problem allein zu lösen.

Speicherung scheint erst mal zu funktionieren, mit new EditorWrapper(org.w3c.dom.Element).

Der Weg über Data scheidet aus, wegen der Umbennung der Linktemplate-Uid's.

Um eine Parsing-Exception zu Umgehen müssen wir das Data-Objekt i.d.R. wegspeichern, die Referenz im Owner nullen. Dann werden die Template-Uids umbennant. Anschließend muss man die Refenzen im Data-Objekt anpassen. Jetzt kann das weggespeicherte, angepasste Data-Objekt zurrückgesetzt werden ohne eine ParsingException zu erzeugen.

Ich verstehe, dass der Weg über die Api von eSpirit preferiert wird, aber machmal geht's halt nicht anders.

(Oder mit meinen Mitteln geht's nicht anders)

Danke auf jeden Fall nochmal für die Unterstützung.

Viele Grüße

Robert Wieser