Berechnete Eigenschaften in Platzhalter und HTML

Wenn man eine Berechnete Eigentschaft implementiert, kann man nun generiertes HTML auch automatisch einbetten lassen, ohne das der Parameter type="html" angegeben werden muss.

Berechnete Spalte in Datentabellen

In den Datentabellen kann man nun berechnete Spalten definieren.

Standardtitel und -hilfetexte für Datenfelder

es ist jetzt möglich Standardtitel und -hilfetexte für Datenspalten und Quellrelationsdefinitionen zu definieren.

Hilfe bei der Einführung

Falls bei der Migration der Anwendung programmierte Felder Standardtitel und -hilfetexte erhalten sollen, stellt sich die Frage wie diese in der Konfiguration etabliert werden. Also, wie stellt man Masken und Ansichten um?

Da die programmierten Standardtexte über die Konfiguration geändert werden können, sticht bei bestehenden Datenbanken immer die Konfiguration. Nur bei der ersten Migration auf das neue Release werden die programmierten Werte einmalig übernommen.

Daraus ergibt sich die Abhängigkeit, dass für die Analyse der optimalen Texte schon das neue Release erforderlich ist, bevor man die Werte programmieren kann. Dann kann man folgende Controller-Action nutzen:

.../bamaintain/AutoFillDefaultEntityTexts?inheritance=ApplyToAll

Diese erzeugt eine Liste alle Kandidaten für Standardtexte. Die Programmierung der Attribute muss manuell erfolgen. Man kann das Ergebnis von AutoFillDefaultEntityTexts nur zum kopieren der richtigen GUIDs nutzen.

Danach muss entweder die Migration der Datenbank wiederholt werden, damit die programmierten Werte (einmalig) angewendet werden, oder über die Controller-Action

.../bamaintain/AutoFillDefaultEntityTexts?assignFromCode=True&commit=True

können alle programmierten Werte auch nachträglich übernommen werden. Falls programmierte Werte nachträglich nochmal geändert und in die Konfiguration übernommen werden sollen:

.../bamaintain/AutoFillDefaultEntityTexts?assignFromCode=True&forceOverwrite=True&commit=True

Jetzt müssen noch die Masken und Ansichten auf die Nutzung der Standardtexte umgestellt werden. Dazu ist die Controller-Action

.../bamaintain/AutoSetUseDefaultEntityTexts?commit=True

aufzurufen. Diese wiederholt das Verhalten der Standardmigration und setzt die Häckchen für die Nutzung der Standardtexte wo immer dieselbe Übersetzung verwendet wird. Bei der letzten Controller-Aktion kann es zu Warnungen kommen, falls zwar die Übersetzung gleich ist, aber nicht deren GUID. Falls dort auch immer die Standardübersetzung verwendet werden soll, muss das Häkchen in der jeweiligen konfiguration manuell gesetzt werden.

BAValidationResult

Wenn eigene Validierungsfehler erzeugt werden, sollte zukünftig die Klasse BAValidationResult anstelle von ValidationResult verwendet werden. Diese bietet zwei zusätzliche Features:

  1. Es kann zusätzlich zum technischen Namen ein Anzeigename für das zu validierende Feld übergeben werden.
  2. Der Validierungsfehler wird nachgelagert übersetzt, was die Ausgabe in verschiedenen Sprachen ermöglicht, um z.B. in ein Anwendungprotokoll in einer vom aktuellen Benutzer abweichenden Sprache schreiben zu können.

In eigenen Validatoren sollte anstelle von new ValidationResult entweder der Konstruktor BAValidationResult(ValidationContext validationContext, string errorMessage, params object[] args) oder alternativ die Hilfsmethode ValidationAttributeHelper.CreateValidationResult verwendet werden.

Falls an der jeweiligen Stelle kein ValidationContext zur Verfügung steht, muss der Konstruktor BAValidationResult(string memberName, string displayName, string errorMessage, params object[] args) verwendet und die Ermittlung des (unübersetzten) Anzeigenamens aus den DisplayNameAttribute selbst implementiert werden.

Es sollten keine übersetzten Texte an den Konstruktor übergeben werden.
Keinesfalls sollte die Fehlermeldung den Feldnamen als Präfix in der Art "[Fehlerhaftes Feld]: " enthalten. Das wird bei den Ausgabekanälen, wo das nicht aus dem Kontext hervor geht (z.B. Logfile), automatisch hinzugefügt.

Die alte Klasse ValidationResult funktioniert weiterhin, kann aber zu unschönen Fehlermeldungen führen.

Api.Html

Es gibt einen neuen API-Block Api.Html. Darin sind Funktionen rund um die Behandlung und Konvertierung von HTML-Datenfeldern. Siehe auch