Das Problem

Im Projekt, das schließlich zur Realisierung dieses Plugins geführt hat, habe ich die Beobachtung gemacht, dass bis zu 80 dynamische Aktionen auf einer Anwendungsseite erforderlich waren, um die Anforderungen dieser Formulare zu implementieren. Gerade Neueinsteiger in die Teams hatten erhebliche Schwierigkeiten, sich in die Arbeitsweise dieser Seiten einzuarbeiten, doch auch die Entwickler haben bei der Änderung den größten Teil ihrer Zeit damit zugebracht, das komplexe Gewebe von Abhängigkeiten zwischen den dynamischen Aktionen neu auszutarieren. Wurde eine weitere dynamische Aktion erforderlich, konnte dies dazu führen, dass andere Funktionen nicht mehr wie gewünscht arbeiteten. Die Fehlersuche war äußerst mühsam und die Kontrolle über die Seite ein Alptraum.

Um die Seiten zu kontrollieren, verwendeten die Teammitglieder Excel-artige Tabellen, um sich die Abhängigkeiten der Seitenelemente von den Benutzereingaben klarzumachen. So konnte zum Beispiel die Auswahl eine Adresstyps als »Firma« erforderlich machen, dass einige Seitenelemente ein-, andere wiederum ausgeblendet werden mussten. Die Eingabe einer Versicherungsnummer zog eine Validierung innerhalb der Datenbank nach sich, die Auswahl eines Dezernates konnte, je nach Dezernat, die Darstellung einer weiteren Auswahlliste mit näheren Strukturangaben nach sich ziehen und so weiter. Diese Listen konnten von allen Teammitgliedern einfach gepflegt werden und wurde gut verstanden. Die Umsetzung dieser Vorgaben in APEX-Code jedoch hat die Entwickler überfordert.

Idee

SCT nutzt Regellisten, um daraus die Steuerung der Anwendungsseite automatisiert abzuleiten. Die Regellisten orientieren sich dabei an den ohnehin vorhandenen Excel-Tabellen, mit denen das Verhalten der Anwendungsseite dokumentiert und kommuniziert wurde. Wird in dieser Regelliste zum Beispiel eingetragen, dass bei der Auswahl des Adresstyps »Firma« zwei Eingabefelder an- und zwei weitere Felder auszublenden sind, kann dies einfach in der Regel notiert werden und die Seite wird die entsprechenden Seitenelemente steuern. Nun ist dieses Beispiel nicht sehr beeindruckend, denn eine solche Funktion lässt sich mit einer dynamischen Aktion ohne Aufwand umsetzen. Sehen wir uns jedoch eine kleine Liste weiterer Aktionen an, wird klar, dass SCT auf Grund seiner Spezialisierung erhebliche Vereinfachungen gegenüber dynamischen Aktionen mit sich bringen kann:

  • Ein Element soll, basierend auf den Benutzereingaben, Pflichtfeld oder optionales Feld sein (und nicht nur so aussehen, eine entsprechende Validierung soll durchgeführt werden)
  • Es soll möglich sein, Felder basierend auf Serverseitigen Bedingungen zu kontrollieren. Dynamische Aktionen können nur auf Bedingungen reagieren, die auf der Clientseite evaluiert wurden. Soll eine Bedingung serverseitig geprüft werden, muss ein Hilfsfeld und eine zweite dynamische Aktion eingeführt werden
  • Es soll möglich sein, spezielle Eingaben wie Versicherungsnummern, IBAN-Ziffern und so weiter ohne großen Aufwand mittels PL/SQL-Funktionen zu validieren  (zum Beispiel als Berechtigungsprüfung gegen den angemeldeten Benutzer) und zu formatieren, das formatierte Ergebnis soll direkt in das Feld eingetragen werden
  • Regeln sollen rekursiv ausgewertet werden können: Wird ein Ereignis ausgelöst, dass einen Wert im Sessionstatus ändert, soll diese Änderung eventuelle weitere Regeln auslösen

Im Kern verlagert SCT also die Steuerung der Anwendungsseite von einer losen Gruppe dynamischer Aktionen zu einer Regeltabelle innerhalb der Datenbank. Dies mag zunächst nicht nach einem sinnvollen Vorgehen klingen, doch ist es das sehr wohl: Hierfür spricht, dass viele dynamische Aktionen ohnehin Aktionen in der Datenbank auslösen müssen, sei es, um Validierenden durchzuführen oder neue Werte zu erfragen. Dynamische Aktionen benötigen hierfür jeweils einen Roundtrip. Da sich dynamische Aktionen nicht bündeln lassen, werden alle Roundtrips einzeln aufgeführt, was zu regelrechten AJAX-Kaskaden zwischen der Anwendungsseite und der Datenbank führt. SCT hat genau einen Roundtrip für jede Regelanalyse, denn da Regeln rekursiv innerhalb der Datenbank gerechnet werden, sind alle Aktivitäten innerhalb der Datenbank dort bereits erfolgt, bevor die endgültige Antwort mit den JavaScript-Aktionen erfolgt.

Würd man dies nicht tun und möchte man andererseits die Vielzahl von dynamischen Aktionen eingrenzen, bliebe als Alternative eine Programmierung der gesamten Validierungs- und Anwendungssteuerungsslogik in JavaScript. Problematisch hieran ist der Verlust des deklarativen Programmieransatzes sowie die Arbeit mit Low Level JavaScript-Code. Nicht gelöst würde bei diesem Ansatz das Problem der häufigen Roundtrips zwischen Client und Datenbank als Folge der geänderten Ausgangslage durch die Benutzereingaben. Vor diesem Hintergrund gewinnt der einmalige Roundtrip an Charme. Allerdings sollte dies nicht übertrieben werden: Eine Validierung, die bei jedem KeyUp-Event die Datenbank anspricht, ist sicherlich nicht sinnvoll und in SCT auch gar nicht möglich.

Umsetzung

Um es gleich vorweg zu sagen: SCT ist kein Ersatz für dynamische Aktionen oder Plugins, sondern im Gegenteil selbst ein Dynamic Action Plugin. Auf der Anwendungsseite wird SCT als dynamische Aktion beim Seitenladen integriert, als einzige Konfiguration ist die Angabe eines Regelbezeichners erforderlich. Dieser Regelbezeichner verweist auf eine Gruppe von Regeln, die für die Kontrolle der Anwendungsseite eingesetzt werden. Die Benennung einer Regelgruppe und die Referenzierung dieses Namens auf der Anwendungsseite erlaubt den Einsatz mehrerer Regelsätze auf einer Seite (nicht gleichzeitig, aber zum Beispiel basierend auf Parametern, die der Seite beim Aufruf übergeben werden). So ist es zum Beispiel möglich, einen Regelsatz zur Erfassung der Produktkategorie A und eine zweite für die Produktkategorie B zu entwerfen, wenn vorausgesetzt werden kann, dass die Produktkategorie während der Darstellung der Seite nicht geändert werden kann.

Folgende Bestandteile werden benötigt:

  • Auf der Anwendungsseiteie wird die dynamische Aktion mit dem Bezeichner der Regelgruppe angelegt
  • In einer separaten APEX-Anwendungen werden die Regelgruppen erzeugt und der Anwendungsseite zugeordnet
  • Eine Regelgruppe besteht aus Einzelregeln, die das Verhalten auf der Seite steuern.
  • Jede Einzelregel besteht im Kern aus einer Bedingung, die als Fragment einer where-Klausel formuliert wird, sowie einer beliebigen Anzahl Aktionen, die festlegen, was passieren soll, falls diese Regel ausgewählt wird. Die Werte der Seitenelemente können in Regelbedingungen wie Spaltenwerte verwendet werden
  • Eine Aktion wird aus einer vorgegebenen Liste von Aktionstypen gewählt und kann sowohl PL/SQL- als auch JavaScript-Aktionen umfassen. Jede Aktion kann mit bis zu zwei Parametern an die Bedürfnisse angepasst werden und hat direkten Zugriff auf den aktuellen Wert des zugeordneten Seitenelements
  • Aktionstypen können vom Entwickler neu erstellt und direkt verwendet werden

Erstaunlich mag zunächst sein, dass außer dem Namen der Regelgruppe keine weitere Administration auf der Anwendungsseite erforderlich ist, doch ist das korrekt so. Die Bindung der Eventhandler, die letztlich dafür sorgen, dass überhaupt etwas auf der Anwendungsseite geschieht, werden durch die Logik des SCT in der Datenbank automatisch erstellt und beim Seitenladen ausgeführt. Welche Elemente tatsächlich beobachtet werden, ergibt sich aus den Regelbedingungen, denn nur Seitenelemente, die in diesen Bedingungen referenziert werden, können eine Reaktion des SCT auslösen. Daher müssen umgekehrt auch nur diese Elemente auf der Seite beobachtet werden, die Anzahl ergibt sich also automatisch aus der Analyse der einzelnen Regelbedingungen. Für den Entwickler hat dies zur Folge, dass keinerlei Interaktion mit Eventhandlern erforderlich ist: Es wird einfach eine Regel angelegt und gesagt, was in diesem Fall geschehen soll, und die Anwendungsseite führt die Aktion aus.

Jede Regel, die in der APEX-Anwendung erfasst wurde, hat unmittelbare Auswirkung auf die Seite, daher können Regeln und Anwendung parallel entwickelt und die Folgen der einzelnen Regeln direkt beobachtet werden. Die Regeln lassen sich einzeln aktivieren oder deaktivieren, um die Auswirkungen auf die Anwendungsseite beobachten zu können. Zudem wird beim Berechnen der Regeln ein Log geschrieben, der in den Entwicklerwerkzeugen ausgegeben wird und direkte Informationen darüber enthält, welche Regel ausgeführt wurde, wie die rekursiven Abläufe in der Datenbank waren und welche Aktionen im Einzelnen ausgeführt wurden.

Funktionalität

Kernfunktion ist die Überwachung von CHANGE-Events auf Eingabeelementen sowie von CLICK-Events auf Schaltflächen. Das Gros der Regeln reagiert auf Änderungen dieser Art. SCT bietet eine Reihe von Funktionen, um zum Beispiel Änderungen am SessionStatus vorzunehmen. Als Wrapper um die APEX-Funktionalitäten erweitern diese Methoden den Prozess insofern, als eine Änderung des SessionStatus innerhalb der Datenbank bei der Antwort von SCT direkt auch an den Browser übergeben wird. Ähnliche Funktionen existieren zum Registrieren von Fehlermeldungen. Neben dieser Kernfunktionalität sind weitere Features implementiert:

  • Seitenelemente können über jQuery-Selektoren angesprochen werden und dadurch die Anzahl der Einzelregeln drastisch reduzieren
  • Schaltflächen werden in SCT sichtbar, wenn ihnen eine statische ID auf der Anwendungsseite zugeordnet wird. So lässt sich die Anzahl der durch SCT überwachten Schaltflächen kontrollieren
  • Neben den genannten Ereignissen lässt sich in SCT auch ein Doppelklick, die Enter-Taste sowie die Event APEXAFTERREFRESH und APEXAFTERCLOSEDIALOG überwachen und mit Regeln verbinden
  • Aktionstypen werden als Standard mitgeliefert, können aber über eine einfache Systematik auch selbst erweitert werden. Jedem Aktionstyp können Parameter übergeben sowie eine PL/SQL- und/oder ein JavaScript-Block zugeordnet werden. PL/SQL-Methoden werden direkt ausgeführt und können rekursive Regeln auslösen, JavaScript-Blöcke werden als Teil der Antwort gesammelt und unmittelbar mit der Antwort auf der Clientseite ausgeführt

Auf Grund der Erweiterbarkeit durch eigene Aktionstypen ist die Mächtigkeit von SCT nicht limitiert. An einem Beispiel wird das klar: Es soll die Anforderung umgesetzt werden, dass spezielle Eingabewerte wie IBAN- oder BIC-Angaben validiert und formatiert werden. Dies wäre durch ein Plugin möglich, dem als Parameter der Typ des speziellen Werts m mitgegeben wird. Alternativ kann in SCT ein Aktionstyp »Spezieller Wert« definiert werden, der als Parameter den Typ des speziellen Wertes entgegennimmt. Eine PL/SQL-Methode nimmt dann den aktuellen Elementwert und diesen Parameter entgegen, prüft die Eingabe gegen entsprechende Logik und formatiert den Wert. Dieser Wert wird anschließend im SessionStatus gesetzt und durch SCT automatisiert an die Oberfläche zurückgegeben. Im Vergleich zu einem Plugin hat dieses Vorgehen eine Reihe von Vorteilen:

  • Es ist kein weiteres Plugin erforderlich, das erstellt, getestet und ausgeliefert werden muss
  • Ein Aktionstyp ist innerhalb weniger Sekunden erstellt, neben der reinen Prüflogik muss nichts weiter implementiert werden
  • Es ist keinerlei Programmierung auf der Anwendungsseite erforderlich, um ein Element als speziellen Wert zu prüfen, die Erstellung eines Aktionstyps und die Verwendung auf der Anwendungsseite in einer Aktion für dieses Element reicht

Die Auslagerung der Aktionen in Aktionstypen hat den Vorteil, dass gleiche Aktionen nicht mehrfach implementiert werden müssen, zudem ist dieser Ansatz deklarativ, d.h. der Entwickler muss die Implementierung nicht kennen. Eine Rollenberechtigung kontrolliert, wer eigene Aktionstypen erstellen darf.

Bei der Erstellung der Regeln werden die Bedingungen und Aktivitäten kontinuierlich gegen das APEX-Data Dictionary getestet. Nicht vorhandene Seitenelemente können in Regeln nicht referenziert werden, ebenso werden die Regeln auf syntaktische Korrektheit überprüft. Schaltflächen und Seitenregionen werden für SCT sichtbar, wenn ihnen eine statische ID zugeordnet wurde. Eingabeelemente werden automatisiert typrichtig konvertiert, wenn den Seitenelementen eine Formatmaske zugeordnet wurde oder wenn die Seitenelemente ihre Daten aus einem Fetch Row-Prozess erhalten und somit eine Zuordnung zu einer Datenbanktabelle haben.

Erstellte Regelsätze lassen sich über die Anwendung exportieren und anschließend mit der Anwendung ausliefern. Die Regeln stellen letztlich nur Daten im Datenmodell von SCT dar und werden daher auf gleiche Weise wie die APEX-Anwendung selbst ausgeliefert: Als SQL-Skriptdatei, die eine SCT-API aufruft und die Daten anlegt.

Das Plugin ist hier verfügbar. 

 

Kommentar schreiben


Sicherheitscode
Aktualisieren