Framework:Formeln:WarumTyped

Expressions – Was ist das und wie baut man das?

In CoPlanner gibt es zwei Arten von Expressions. Zu Beginn wurden in CoPlanner non-typed Expressions verwendet, das sind die „klassischen“ Expressions, die an vielen Stellen im CoPlanner verwendet werden.

Im Lauf der Zeit hat sich jedoch herausgestellt, dass der Ansatz, der in non-typed Expression verwendet wird (vielfach werden da einfach Teile eines Strings ersetzt) Einschränkungen hat und gewisse Aufgabenstellungen mit diesen Expressions nicht lösbar sind. Als Reaktion darauf wurden die sog. typed Expressions entwickelt.

Der wesentliche Unterschied zwischen typed und non-typed Expressions ist die Art und Weise wie Strings behandelt werden.

Zusätzlich haben Berechnungen mit typed Formeln eine etwas bessere Performance.

Warum sind Strings in typed anders gebaut?

Mit non-typed Formeln gibt es Fälle, in denen man in Formeln Werte zuweisen will, dies in den Formeln aber nicht möglich oder nur sehr kompliziert zu bewerkstelligen ist. Der Grund dafür ist, dass es in der ursprünglichen Variante der Expressions keine Unterscheidung gibt, zwischen dem „was der Ausdruck ist, der berechnet werden soll" und dem "was der Inhalt der Daten ist, mit denen gerechnet wird“.

Dies kann anhand von zwei einfachen Beispielen illustriert werden:

Beispiel 1

Man erstellt eine Tabelle mit zwei Textspalten t1 und t2, dazu eine Same-Formel, die das Flag für typed nicht gesetzt hat und die ganz einfach den Wert von t1 auf t2 schreibt.

Wenn man jetzt in der Tabelle eine Zeile erzeugt und in t1 den String „1+2“ eingibt, dann wird auf t2 mit der Same-Formel der String „1+2“ geschrieben.

Jetzt ändert man den String in t1 auf „(1+2)“ - und erhält in t2 den String „3“ – in diesem Fall wird der Ausdruck von nicht-typed Expressions so interpretiert, dass hier eine Berechnung durchzuführen ist.

-> Mit typed Expressions wird in beiden Fällen der String einfach weitergeschrieben.

Beispiel 2

Man hat eine Tabelle mit einem Wertfeld w und einem Textfeld t. Jetzt möchte man in das Textfeld folgendes schreiben:

„[MeinWert] hat den Wert [w]“.

Hierbei soll statt [w] der Wert des Wertfeldes stehen, also in einer Zeile mit w=5 soll in t folgender Text stehen:

„[MeinWert] hat den Wert 5“.

Um das mit einer Same-Formel mit typed calculation zu rechnen, gibt man folgenden Ausdruck an:

'[MeinWert] hat den Wert' + [w]

Damit erhält man das gewünschte Ergebnis.

Ändert man den Typ der Formel auf nicht typed, so bekommt man einen Fehler, da [MeinWert] nicht aufgelöst werden kann. Auch die Verwendung von Escape-Zeichen wie z.B. „\“, oder das Quoten löst das Problem nicht.

Typed Expressions: Warum sind manchmal Anführungszeichen notwendig und manchmal nicht?

Wenn man eine Expression in einer Formel (oder an anderer Stelle) baut, dann will man häufig den Kontext des aktuellen Datensatzes verwenden, dazu ein einfaches Beispiel:

Man hat eine Tabelle MeineTabelle, in der es einen „Wert LC“, einen „Steuersatz“ und dann ein Feld „Steuer“ gibt. Jetzt will man in einer Formel aus „Wert LC“ und „Steuersatz“ die Steuer errechnen.

Dazu baut man jetzt eine Update-Formel, und in jeder Zeile muss dann mit den tatsächlichen Werten gerechnet werden. Dazu schriebt man jetzt folgendes in den Quellausdruck:

[Wert LC] * [Steuersatz]

Für jede Zeile, in der die Berechnung jetzt durchgeführt wird, wird mit den aktuellen Werten gerechnet, z.B. für eine Zeile mit „Wert LC“ 30 und „Steuersatz“ 0.1 ergibt sich ein berechneter Wert von 30*0.1 = 3 – dieser Wert wird dann in weiterer Folge verwendet (und in der Update-Formel geschrieben).

Jetzt gibt es beim Bauen von Ausdrücken aber auch Stellen, an denen man Spalten einer Tabelle referenziert, dies aber nicht im aktuellen Kontext ausgewertet werden soll.

Ein einfaches Beispiel dafür ist FKT_SUM: Bei den Parametern werden Eigenschaften festgelegt, welche die Zieltabelle, aus der man Lesen will, betreffen, und die nicht durch den aktuellen Kontext ersetzt werden dürfen. Dies kann man bei einer Expression erreichen, indem man (Teile der) Ausdrücke unter Anführungszeichen setzt. In obigem Beispiel könnte es z.B. der Fall sein, dass der Steuersatz in einer eigenen Tabelle Steuersaetze steht und dies über eine Dimension „Steuerschluessel“ abgebildet ist.

Der Ausdruck würden dann wie folgt aussehen:

[Wert LC] * FKT_SUM('Steuersaetze.Wert LC', 'Steuerschluessel me ' + [MeineTabelle.Steuerschluessel])

Warum sind jetzt Teile des Ausdrucks unter Anführungszeichen und andere Teile nicht? Schauen wir uns doch kurz den Ausdruck an:

• [Wert LC] - hier soll mit dem aktuellen Wert der Zeile gerechnet werden => keine Anführungszeichen
• FKT_SUM('Steuersaetze.Wert LC', - hier wird angegeben, welche Spalte aus der Zieltabelle gelesen werden soll, dies muss so stehen bleiben und darf nicht durch den aktuellen Kontext ersetzt werden => Anführungszeichen
• 'Steuerschluessel me' hier wird angegeben, welche Spalte in der zu lesenden Tabelle gefiltert werden soll (inklusive Filteroperator) – dies betrifft ebenfalls die Zieltabelle von FKT_SUM und darf nicht durch den aktuellen Kontext ersetzt werden => Anführungszeichen
• + [MeineTabelle.Steuerschluessel]) der Filter soll Zeilen lesen, bei denen der Steuerschlüssel mit dem Schlüssel der aktuellen Zeile übereinstimmt => hier soll der Kontext der aktuellen Zeile genommen werden. Da FKT_SUM einen Text für Filter mit Operator und Zielwert erwartet, wird der Text für Zielspalte und Operator mit „+“ mit Stuerschluessel des aktuellen Datensatzes verknüpft.

Weiteres Beispiel mit Verwendung von FKT_Set (mit FKT_Set kann man in einer Matrixmaske die in einer Dimension verfügbaren Elemente festlegen):

FKT_SET('[MeineDimension.MeinAttribut] = ‘+ @Meine_AW@)

Betrachten wir auch hier wieder die einzelnen Teile des Ausdrucks:

• '[MeineDimension.MeinAttribut] = ‘ Das Attribut von MeineDimension soll erst bei der Ausführung von FKT_Set ausgwertet werden und nicht schon im aktuellen Kontext => Anführungszeichen verwenden
• @Meine_AW@ Die Anwendungseigenschaft kann im aktuellen Kontext ausgewertet werden => keine Anführungszeichen.

Da es aber letztendlich keine Rolle spielt, ob die Anwendungseigenschaft bereits im aktuellen Kontext oder erst bei Ausführung von FKT_Set ausgewertet wird, könnte man den Ausdruck auch wie folgt formulieren:

FKT_SET('[MeineDimension.MeinAttribut] = @Meine_AW@‘)

Strings in Strings

Will man in typed einen String innerhalb eines Strings verwenden, dann kann man das durch die Verwendung von einfachen und doppelten Anführungszeichen erreichen.

Man möchte wie in obigem Beispiel in einer Formel für eine Zeile mit dem Wert 5 folgenden Text schreiben:

Der Wert von „meinem Wert“ ist 5.

Dazu würde man folgenden Ausdruck verwenden:

Der Wert von „meinem Wert“ ist ' + [w] + '.'

Dies wird z.B. für komplexere Abfragen in FKT_Set benötigt.

Zusammenfassung

Vereinfacht zusammengefasst: Wenn man eine typed expression baut und

• in einem Ausdruck Platzhalter durch Werte der aktuellen Zeile ersetzt werden sollen => keine Anführungszeichen
• Parameter „as is“ ohne Ersetzen durch den aktuellen Kontext an eine Funktion übergeben werden sollen => Anführungszeichen