graulich
I'm new here

Ersatz für "de.espirit.firstspirit.module.Editor"

Hallo zusammen,

habe das Forum schon durchsucht und leider nichts zu dem Thema gefunden. Im ODFS konnte ich ebenfalls nichts brauchbares finden.

Wir haben ein FS 4.1 Modul welches ein eigenes FS-Eingabeelement / einen Editor bereitstellt. Dieses Modul soll nun für FS 5 gängig gemacht werden.

Der durch das Modul bereitgestellte Editor implementiert "de.espirit.firstspirit.module.Editor". Dieses Interface ist allerdings als @Deprecated markiert (gibt es da Ersatz?!?).

getEditorValueClass des Editors liefert ein Class-Objekt (EditorContentValueImpl) welches von uns implementiert wurde und AbstractEditorValue<EditorValueObject> extended und EditorValue implementiert. Also folgendermaßen:

public final Class<? extends EditorValue<?>> getEditorValueClass() {

        return EditorContentValueImpl.class;

}

public class EditorContentValueImpl extends AbstractEditorValue<EditorValueObject> implements EditorValue {

...

Unser Problem ist, dass bspw. die Save, Unlock und Refresh Operationen auf einem Inhalt (welcher ein Template instanziiert welches unseren Editor nutzt) nicht korrekt an die parseValue bzw. formatValue Methoden der EditorContentValueImpl weitergeleitet werden.

Bspw. sollte formatValue bei Strg+S und Language-Tab-Wechsel aufgerufen werden und parseValue bei F5 - wenn ich korrekt informiert bin. Sollte ich falsch liegen, bitte korrigieren. Smiley Wink

Aktuell wird zumindest die parseValue Methode aus dem Client heraus gecalled, wenn wir den Inhalt speichern.

Diese Methode aus EditorContentValueImpl sieht wie folgt aus:

@Override

protected final EditorValueObject parseValue(final Language language, final HashMap<String, Element> attributes) {

Der Parameter attributes wird leider nicht aktualisiert und beinhaltet die initial gesetzten Werte des Editors - woran könnte das liegen?

Beste Grüße

Dominic

PS: Gerne sende ich isolierte Code-Beispiele via Mail...

4 Replies
feddersen
Community Manager

Hallo Dominic,

ganz allgemein sollte mit FirstSpirit5 das neue Komponentenmodell verwendet werden, welches mit FirstSpirit 4.2R4 eingeführt wurde. Siehe http://www.e-spirit.com/odfs50/media/dokumentation/dokumentation_entwickler/MDEV50DE_FirstSpirit_Mod... Kapitel 3.

0 Kudos

Hallo zusammen,

habe die Eingabekomponente auf PUBLIC/SwingGadgets umgestellt.

Wie komme ich an die Events heran, die bei Reload, Save, Lock/Unlock geworfen werden?

Lock/Unlock wird ja bereits über setEditable des AbstractValueHoldingSwingGadget's in die EIngabekomponente "kommuniziert" - wie sieht es mit den anderen "Events" aus?

Beste Grüße

Dominic

0 Kudos

Soweit ich das sehe musst du dich gar nicht um Reload kümmern, das macht das umliegende Framework. Wenn es den aktuellen Wert braucht, zum Beispiel weil der Redakteur ein Reload gemacht hat, dann wird der aktuelle Wert aus deiner Komponente angefragt.

Ja, das stimmt.

Sorry, dass ich kein Feedback gegeben habe. Das Framework zieht sich die Werte über get- und setValue. Man braucht sich um die Events garnicht kümmern.

Die SwingGadgets sind ziemlich cool umgesetzt.

Grüße

Dominic

0 Kudos