Questions & Answers

[aVogt]

Hallo,

ich stelle gerade auf FS5.2R4 um (von FS5.1R3) .

Bei der Ermittlung von Werten der Eingabekomponenten gehe ich bisher immer über die entsprechenden **EditorValue Klassen (z.B. DomEditorValue). Die darin enthaltene Methode get(Language language)  stammt aus der Klasse EditorValue(), die komplett deprecated ist.

Um es relativ flexibel zu halten, bin ich bei Ermittlung der Werte  bisher immer über den EditorWrapper gegangen und dann getAccessEditor(..);

**EditorValue  value = ((EditorWrapper) entity.getValue("Aenderungsgrund")).getAccessEditor(context.getUserService(), true);

Dieser Weg scheint jetzt nicht mehr zum Ziel zu führen.

Empfohlen (glaube ich) ist der Weg über FormData, da benötige ich bei Entitys aber immer ein Content2 (und somit immer die Datenquelle). Das finde ich etwas umständlich.

Der Hinweis in EditorValue „since 5.2.21 - use ValueEngineer instead“ führt zu einer dev-Klasse.

Wenn auf eine dev-Klasse verwiesen wird, wie stabil ist diese in zukünftigen Versionen und wie komme ich an den ValueEngineer. Bekomme ich darüber den Wert der Eingabekomponente?

Die Beispiele zum Ermitteln der Werte in der Api gehen noch über die **EditorValue-Klassen. Werden diese angepasst?

Ist der empfohlene Weg immer über FormData, oder gibt es einen anderen schnelleren Wert um von einer Entity an die Werte zu kommen, ohne über FormData zu gehen?

Wahrscheinlich stehe ich wieder mal auf’m Schlauch….

Grüße

Andreas

[mbergmann]

Hallo Andreas,

richtig, der empfohlene Weg ist immer, über ein FormData zu gehen. Insbesondere beim Schreiben von Werten, da nur hier z.B. die Regeln greifen.

Zunächst mal: Dein bisheriger Weg ist nicht nur @deprecated, sondern komplett außerhalb der API, da der EditorWrapper gar nicht Teil der API ist. Der ValueEngineer führt Dich hier in die falsche Richtung, das ist eher von Belang wenn man eigene Eingabekomponenten baut.

Um zu einer Entity ein Dataset und damit ein FormData zu bekommen, brauchst Du nicht unbedingt ein Content2 (=eine Datenquelle). Hier gibt es nämlich auch den Weg über das TableTemplate, das (wie ein Content2) ein DatasetProvider ist. Darüber kommst du letztlich per TableTemplate.getDataset(Entity entity) an ein Dataset - das in diesem Fall keine Datenquelle hat. Die Methode Dataset.getParent()liefert da auch einen Hinweis:

"Returns parent Content2 which can be null if this dataset (or it's entity) is only associated with a table-template."

Zum Thema DEV-API (auch wenn es in Deinem Fall letztlich doch nicht relevant ist): Hier gibt es lediglich etwas geringere "harte" Garantien was die "Stabilität" angeht. Mit Stabilität ist dabei aber nicht die "funktionale" Stabilität gemeint (im Sinne von "funktioniert vielleicht nicht", "ist noch Beta" o.Ä.) sondern lediglich der garantierte Zeitraum (bzw. Versionsbereich) in dem keine rückwärts-inkompatiblen Änderungen vorgenommen werden. Der ist für die DEV-API streng genommen lediglich innerhalb einer Minor-Version (d.h. im Allgemeinen ca. 15 Monate). Wenn ich mir da so andere Softwarehersteller ansehe, ist selbst das schon recht lang 😉 In der Praxis ist es außerdem so, dass hier zwar öfters (z.B. bei neuen Features) Dinge hinzukommen (was ja nicht stört). Aber dass wirklich rückwärts-inkompatible Änderungen gemacht werden, kommt nur sehr selten tatsächlich vor - und dann gibt es eigentlich immer auch früh genug vorher ein @deprecation announcement. Mir persönlich fällt zumindest in der 5er-Linie gerade kein Fall ein, wo es anderes gewesen wäre... Von daher kann man (bis auf entsprechend in der API dokumentierte Einzelfälle) die DEV-API meiner Erfahrung nach im Allgemeinen bedenkenlos verwenden.

Viele Grüße

Michael