Regeln – Dynamische Formulare erstellen

Ein Vorlagenentwickler kann über die Definition von Regeln innerhalb der (Formular)-Vorlage bestimmte Elemente oder Eigenschaften des Formulars beeinflussen und so ein „Dynamisches Formular“ erstellen. Regeln können überall dort eingesetzt werden, wo FirstSpirit-Formulare verwendet werden und zwar sowohl im SiteArchitect als auch im ContentCreator, z. B. in:

• Formularen für die Inhalte- und Datenquellen-Verwaltung
• Metadaten-Formularen
• Formularen für Arbeitsabläufe
• Formularen für Skripte
• Formularen für Verweisvorlagen

Dynamische Formulare ermöglichen:

• Die Erkennung von inhaltlich ungültigen Zuständen in Formularen. So kann beispielsweise geprüft werden, ob ein Datum je nach Anforderung der jeweiligen Eingabekomponente – in der Zukunft (z. B. kommende Termine) oder in der Vergangenheit (z. B. Pressemitteilungen) liegt.
• Das Ausblenden einzelner Eingabefelder eines Formulars unter bestimmten Bedingungen. Auf diese Weise kann beispielsweise die Anzeige und Bearbeitung durch bestimmte Benutzergruppen unterbunden oder die Bearbeitung von einzelnen Feldern nur noch in bestimmten Verwaltungen zugelassen werden.
• Das Herstellen logischer Beziehungen zwischen Formularelementen, die zu einer automatischen Veränderung eines abhängigen Feldes führen. So kann z. B. die Auswahl zwischen zwei Lieferanten über eine Checkbox eine abhängige Combobox beeinflussen, die je nach Wahl nur bestimmte Produkte anzeigt.

Die Auswertung der Regeln auf dem entsprechenden Formularelement kann zu unterschiedlichen Zeitpunkten im redaktionellen Arbeitsprozess erfolgen:

• direkt während der redaktionellen Arbeit (bei jeder Eingabe),
• beim Speichern oder
• beim Wechsel in den Bearbeitungmodus bzw. bei der Neuanlage

(Siehe dazu auch <RULE/>-Tag.)

Ist eine Regel verletzt (<VALIDATION/>-Tag), wird dies für alle Elemente einheitlich visualisiert. Die Darstellung unterscheidet sich dabei klar vom sonstigen Layout des Arbeitsbereichs, um fehlerhafte Eingaben deutlich hervorzuheben. Neben einer farblichen Kennzeichnung, die abhängig von der zugrundeliegenden Restriktionsstufe ist, umfasst die Visualisierung auch eine textuelle, sprachabhängige Begründung, warum der Zustand ungültig ist. Der Ersteller des dynamischen Formulars (also der Vorlagen-Entwickler) kann dann entscheiden, wie mit Elementen in diesem Status im weiteren Redaktionsablauf verfahren werden soll, beispielsweise ob sie bei einer Generierung berücksichtigt werden sollen.

Hinweis: Über die Option „Sprache validieren“ in den Eigenschaften des gewünschten Projekts im FirstSpirit ServerManager im Bereich „Sprachen“ kann die Validierung für einzelne Sprachen deaktiviert werden. Siehe dazu auch Sprachen (→Dokumentation für Administratoren).

Ergänzungen zu dieser Dokumentation

Beispiele

• Beispiel-Projekt Dynamische Formulare (Version 2024.5) (Projekt mit vielen Beispielen zur Regeldefinition)
• Beispiel ValueService (Version 0.1) (Beispiel-Modul)

FirstSpirit API

Access-API-Dokumentation:

• Interface SaveOperation
  Über dieses Interface kann das Speichern von Store-Elementen und Datensätzen programmatisch umgesetzt werden. Mithilfe der Methode setValidationEnabled(false) kann ein Speichern auch dann erfolgen, wenn das betreffende Element fehlerhafte oder ungültige Daten enthält, z. B. eine Regel verletzt ist.
• Interface Language
  Über die Methoden setIgnoreValidation() kann bestimmt werden, ob die Validierung für eine bestimmte Sprache de-/aktiviert werden soll.
• Interface ValidationAgent
  Dieses Interface bietet Zugriff auf Funktionen, um Formulardaten gegen die im Formular definierten Regeln zu validieren. Dieser Validitätsstatus wird beispielsweise innerhalb von Arbeitsabläufen benötigt, um zu prüfen, ob ein Element freigegeben werden darf.

Einschränkungen

Validierung von referenzierten Datensätzen in FS_INDEX

Für Eingabekomponenten, die Datensätze referenzieren und darstellen, ist eine generelle Validierung aller inneren Objekte sowohl aus redaktioneller Sicht als auch aus Performancegründen nicht immer gewünscht.

Für die Validierung einer Eingabekomponente FS_INDEX gilt :

• Fehler aufgrund von verletzten Regeln in referenzierten Datensätzen werden in der Eingabekomponente nicht mehr berücksichtigt, wenn das entsprechende Unterformular nicht sichtbar ist. Eine Regelverletzung in einem referenzierten Datensatz verhindert aber nicht das Speichern oder die Freigabe des gesamten Formulars. Dieses Verhalten betrifft nur assoziierte Datensätze.