16. NEU ab V5 - pulsation Designer (erhältlich ab Q4/2021)

Modulbeschreibung

Inhalt des pulsation Designers sind die Generic Views.

Der pulsation Designer bietet mit den Generic Views eine vollständig neue Technologie zur Verbesserung der Datenerfassung. Generic Views beschreiben, wie Daten erhoben werden sollen und ermöglichen damit das Konfigurieren von Eingabemasken.
Bisher waren Anpassungen der Datenerfassung mit hohem Entwicklungsaufwand verbunden. Mit Hilfe des pulsation Designers werden diese Aufwände maßgeblich verringert.

Generic Views sind eine Art Weiterentwicklung der dynamischen Felder. Der Kunde wird hiermit in die Lage versetzt, sich eigene Eingabemasken zu bauen.

Anwendungsbeispiel:

Der Kunde konfiguriert sich eine neue Eingabemaske. Diese Generic View erstellt er mit dem pulsation Designer und bindet diese z.B. in die Notfalldokumentation ein.

In diesem Artikel werden die folgenden Funktionen von Generic Views erläutert:

Erstellen einer View mit dem pulsation Designer

Einbinden einer View in das pulsation Notfallprotokoll

Einbinden einer View in das pulsation BTK-Protokoll

Video 1: Vorstellung des Abfrage Algorithmus

Anleitung

Um die gesamte Funktion der Generic Views aufzuzeigen, wird betrachtet, wie eine neue Maske konfiguriert und wie eine Generic View in ein bestehendes Protokoll eingebunden werden kann.

pulsation Designer
Im Designer können Sie eine eigene Eingabemaske zusammenbauen.
Um den Designer zu verwenden öffnen Sie die pulsation WebApp und navigieren Sie zu Stammdaten-> Setup → Generic View Designer

Abbildung 1: Generic View Designer in der Web-App

Nachdem Sie den Reiter ausgewählt haben, sehen Sie eine Liste Ihrer erstellten Eingabelisten. Um eine neue Maske zu erstellen, klicken Sie oben links auf “Anlegen”.

Anschließen gelangen Sie in die Editor-Ansicht. Diese teilt sich in 3 Bereiche:

Komponenten (Links)

Komponenten sind Eingabeelemente, mit denen der Benutzer Ihrer View interagieren kann.
Alle Komponenten (auch Rows genannt) finden Sie hier (Muss noch ausgearbeitet werden)

Ansicht (Mitte)

Im Bereich Ansicht sehen Sie eine Vorschau Ihrer Eingabemaske.
Auf dem iPad z.B. wird Ihre Maske genauso aussehen.

Eigenschaften(Rechts)

Im Bereich Eigenschaften können Sie Eigenschaften Ihrer View, Section und Row anpassen.
Beispielsweise können Sie hier den Namen Ihrer View festlegen oder einem Freitextfeld einen Platzhalter geben.

Aufbau einer View

Im Designer wird eine eigene Eingabemaske konfiguriert, dabei ist der Aufbau immer derselbe.
Eine View besteht aus 3 Teilen:

Die View
Die View ist eine Art Hülle für Sections und Rows und hält rudimentäre Daten wie z.B. den Namen Ihrer Maske.

Sections (Sektionen)
Eine View kann aus vielen Sections bestehen. Eine Section dient zur Gliederung Ihrer Maske. Sie bündelt Ihre Rows zu Blöcken und macht die View übersichtlicher. Eine Section besitzt z.B. einen Namen und mehrere Rows.

Rows (Komponenten)
Rows sind die Eingabeelemente Ihrer Maske wie z.B. ein Freitextfeld, eine Auswahlliste oder ein Ja/Nein Button.

In Abbildung 3 wird eine View aufgezeigt, welche aus zwei Sektionen besteht. Die erste Sektion beinhaltet ein Textfeld mit dem Namen “Mein Textfeld“. Die zweite Sektion beinhaltet eine Ja/Nein Zelle.

Zusammengefasst besteht eine View aus mehren Zeilen an Eingabeelementen. Diese werden zu Sektionen gruppiert.

Grundkonfiguration der View

Versuchen Sie eine neu erstellte View zu speichern, werden Ihnen höchstwahrscheinlich Pflichtfelder angezeigt werden, welche Sie ausfüllen müssen. Diese werden Ihnen immer in Rot angezeigt.

Die neu erstellte View ist zu Beginn leer. Um die erste Grundkonfiguration vorzunehmen, schauen Sie sich links die Eigenschaften an.

Hier finden die als erstes die Eigenschaften Ihrer View:
Kategorie
Hier können Sie einen beliebigen Text vergeben, um Ihre Masken zu kategorisieren.
Bsp.: Sie erstellen ein Modul, welches aus mehreren Masken besteht und wollen diese leichter in der Übersicht wiederfinden.

View-ID
Eine eindeutige ID Ihrer Maske, diese wird automatisch erzeugt und ist für die Einbindung Ihrer Maske wichtig.
Bsp.: Wenn Sie Ihre Maske in das Notfallprotokoll oder BTK-Protokoll einbinden wollen.

View-Name (iPad) *
Der Name Ihrer Maske, welcher z.B. auf dem iPad angezeigt wird.

View-Name (intern) *
Der Name mit dem Sie Ihre View in der WebApp oder in Statistiken suchen können.
Dieser muss immer eindeutig sein.

Aktiv
Ist eine View aktiv, wird sie z.B. auf dem iPad angezeigt. Ist sie nicht aktiv, wird Sie nicht angezeigt.

Separator
Ein optischer Trenner zwischen den einzelnen Komponenten. (Aktivierung empfohlen).

Scrollbar
Erlaubt das Scrollen in Ihrer Maske (Aktivierung empfohlen).

Häkchen anzeigen

Wird ein Feld auf einem Endgerät bearbeitet, wird ein farbiges Häkchen angezeigt (Aktivierung empfohlen).

Nicht auf Protokoll drucken
Erlaubt das Drucken auf das Protokoll. Es können auch Rows (Komponenten) einzeln angesteuert werden (Aktivierung empfohlen).

Erstellen einer Sektion

Eine View besteht immer aus mindestens einer Sektion. Klicken Sie auf “Das kleine Viereck mit dem Stift” im Bereich Ansicht, um die Sektion auszuwählen. Im rechten Bereich “Eigenschaften” sollten Sie nun eine Zeile mit dem Name “Gewählte Sektion“ sehen.

Um eine weitere Sektion zu erstellen, klicken Sie im Bereich Ansicht auf die Schaltfläche “+ Sektion zufügen“

Sektion-ID
Automatisch generierte ID der Sektion

Sektion-Name (iPad) & Sektion-Name (intern)
Hier können Sie der Sektion einen Namen geben. Dies ist analog zum View-Namen. Sektionsnamen sind keine Pflicht.

Aktiv
Die Sektion ist ist z.B. auf dem iPad nur sichtbar wenn “Aktiv” ausgewählt ist.

Nicht auf Protokoll drucken
Wenn aktiv, können Rows der Sektion auf das Protokoll gedruckt werden.

Hinzufügen einer neuen Komponente

Um Ihrer Maske eine Komponente hinzuzufügen, ziehen Sie mit Drag&Drop die Komponente in den Bereich Ansicht. Sie können die abgelegten Komponenten beliebig in der Reihenfolge verschieben.

Nach dem Sie die Komponente hinzugefügt haben, klicken Sie auf “Das kleine Viereck mit dem Stift”.

Im rechten Bereich “Eigenschaften” sollte nun ein Abschnitt “GEWÄHLTE ZEILE“ sichtbar sein. Ihre Komponente verfügt hier über die folgenden Eigenschaften:

Zeilen-ID
Intern generierte eindeutige ID

Zeilenname (iPad) *
Der Anzeige Name Ihrer Komponente z.B. “Mein Zusatzangaben“

Zeilenname (intern) *
Interner Name für Filter und Statistiken. Der Name muss Eindeutig sein z.B. “Mein Zusatzangaben aus Maske Zusatz“

Zeileninformation
Jede Komponente verfügt über ein Informationsfeld. Dies wird z.B. auf dem iPad angezeigt.
Mit dem Informationsfeld können Sie dem Benutzer Ihrer Maske zusätzliche Informationen zu Ihrer Komponente zukommen lassen.

Zeilenhöhe
Höhe der Komponente in Pixel (Standard = 70)

Aktiv
Wenn nicht aktiv, wird die Komponente ausgeblendet.

Nicht auf Protokoll drucken
Wenn aktiviert wird die Komponente nicht auf das Protokoll gedruckt.

Konfiguration einer Komponente

Jede Komponente kann über eine Konfiguration verfügen. Konfigurationen sind spezielle Einstellungen die für jede Komponente unterschiedlich sein können.

So besitzt die “Ja/Nein Zelle” z.B. keine Konfiguration. Die “Auswahl“ Komponente besitzt hingegen einige Konfigurationsmöglichkeiten.

Die Konfigurationen selbst sind einfache Schlüssel / Wertpaare, mit einer Beschreibung über Ihre Auswirkung.

Validierung einer Komponente

Komponenten können Validierungen hinzugefügt werden. Eine Validierung löst ein bestimmtes Verhalten einer Komponente aus. Mithilfe von Validierungen wird aus einer einfachen Maske ein komplexer Abfrage Algorithmus.
Eine Validierung besteht aus den folgenden Elementen:

is_required
Wenn aktiviert werden Validierungen der Komponente berücksichtigt. Der Wert wird automatisch gesetzt wenn eine dependency_validation hinzugefügt wird.

error_msg
Zeigt dem Benutzer die eingetragene Nachricht, wenn die Validierung ausgelöst wird.

validation_rule, hidden_rule, enabled_rule & warning_rule
Tipp: Vorher dependency_validation lesen
Mit diesem Feld lassen sich mehrer dependency_validation Objekte kombinieren.
Dabei hat jeder dependency_validation-Typ ein eigenes Feld (validation_rule, hidden_rule ….).

In die oben genannten Felder lassen sich logische Operationen eintragen.
Bsp.: (A && b), (A || b) , (A && (B ||C))

Standardmäßig werden mehrere dependency_validations verodert.

Bsp.:

Gegeben sind:

Komponente: Zahlen Feld mit dem vom Benutzer erfassten Wert 15

dependency_validation A vom Typ Error, prüft auf Wert == 15

dependency_validation B vom Typ Error, prüft auf Wert > 5

#Test 1
validation_rule = ““ (Leer)
Ergebnis = Validierung löst aus!
dependency_validation sind Standardmäßig verodert

#Test 2
validation_rule = “A && B“
Ergebnis = Validierung löst nicht aus!
Es müssen beide Bedingungen erfüllt werden.

dependency_validation
Eine dependency_validation ist ein Objekt, welches ein Event in einer Komponente auslöst.
Bsp.:

Ein Feld ausblenden, wenn in dem Feld darüber “Katze“ steht

Mein Feld zu einem Pflichtfeld machen

validaton_kind

Error = Die Komponente zeigt einen Fehler an, z. B. ein Pflichtfeld, welches ausgefüllt werden muss.

Hidden = Die Komponente wird ausgeblendet, z. B. um eine weitere Abfragen zu einer bestimmten Auswahl in einer vorherigen Abfrage vorzunehmen.

Enabled = Um die Benutzerinteraktion mit der Komponente zu sperren, z. B., um den einen Wert nicht mehr ändern zu lassen, ihn aber dennoch anzuzeigen.

Einer Komponente können beliebig viele dependency_validations hinzugefügt werden. Dabei bekommt jede dependency_validation einen Buchstaben zugewiesen, z. B. A, B, C..Z

validation_type

Im validation_type einer dependency_validation wird angegeben, auf welchen Typ von Wert geprüft werden soll:
functionValidator = Eine Funktion mit einem Namen (Nur für Entwickler)
static = Auf ein Datenbankfeld (Nur für Entwickler)
Dynamic = Auf einer andere Komponente (Dies wird in den meisten Fällen verwendet)

query_destination

Hier wird der Ort des abzufragenden Feldes angegeben.
BTK_ Hauptbericht = Das Feld befindet sich im Hauptbericht der BTK Dokumentation
BTK_MittelBericht = Das Feld befindet sich im Mittelbericht der BTK Dokumentation
Einsatz = Das Feld befindet sich im Notfallprotokoll
Global = Sonderfälle (Nur für Entwickler)

query
Die Query hält unterschiedliche Werte, je nach dem was in das Feld validation_type eingetragen wurde.
Um es an dieser Stelle zu vereinfachen, betrachten wir ausschließlich eine dependency_validation vom Typ “Dynamic“

In der Query wird die Komponente angegeben, auf welche geprüft werden soll. Befindet sich die gesuchte Komponente in der selben Maske, wird im Designer ein DropDown-Menü angeboten in der ein Feld ausgewählt werden kann.

comparator
Ein logischer Ausdruck, wie das Feld ausgewertet werden soll, z. B. ist es >, <, beinhaltet es einen Text.

value_type
Der Typ des Wertes, in der angegebenden Komponente, z. B. Bool, String, Int,…
Die Werte können aus der Komponentendokumentation entnommen werden (Wird noch ausgearbeitet).

value
Der Wert, auf welchen geprüft werden soll, z. B. “Mein Text“, 5 , true.

Tipp: Soll ein Feld ein Pflichtfeld werden, einfach auf den Button “+ Nullcheck zufügen“ klicken.

Speicherregeln einer Komponente

Die Speicherregel einer Komponente beschreibt, wo das Feld gespeichert werden soll.

storage_type
Dynamic = Verwaltet das Speichern der Komponente selber (voreingestellt).

Static = Nur für Entwickler

storage_destination
Hier wird angegeben, wo das Feld gespeichert werden soll.
BTK_ Hauptbericht = Das Feld wird im Hauptbericht der BTK-Dokumentation gespeichert
BTK_MittelBericht = Das Feld wird im Mittelbericht der BTK-Dokumentation gespeichert
Einsatz = Das Feld wird im Notfallprotokoll gespeichert
Global = Sonderfälle (Nur für Entwickler)

storage_destination_attribute
Die Speicheradresse der Komponente ist voreingestellt und sollte nicht verändert werden.

server_query
Nur für Entwickler

server_function
Nur für Entwickler

Verwendung von Generic Views am Beispiel einer Dokumentation einer Brandmeldeanlage