Wenn du diesen Post liest, weißt du wie lange sich viele von uns schon mit Oracle Forms beschäftigen. Mit meinen Best Practices bin ich 1992 gestartet in Trainings, meinem Blog Talk2Gerd, DOAG-Konferenzen und der Oracle Open World, und egal ob alte Hasen oder Neulinge: Immer noch treffe ich auf dankbare Gesichter, wenn ich meine Fundgrube öffne. Die beliebtesten Tipps habe ich jetzt in einer Serie zusammengefaßt, vor der du gerade stehst oder vermutlich eher sitzt. Aber wir wollen keine Zeit verlieren! Und los geht’s:
Eine einzelne Oracle-Forms-Maske hast du schnell gebaut. Ein Datenblock, ein paar Items, einige Trigger – und die Anwendung tut, was sie soll. Die eigentliche Herausforderung beginnt, wenn aus einer Maske fünfzig, hundert oder mehrere hundert werden. Dann entscheidet nicht mehr die Geschwindigkeit beim Erstellen der nächsten FMB über die Qualität der Anwendung, sondern die Frage, wie konsequent wiederkehrende Aufgaben nur einmal gelöst werden.
Genau darin liegt die wichtigste Best Practice aus meiner langjährigen Projektarbeit: Eine große Forms-Anwendung braucht ein Framework. Gemeint ist kein möglichst kompliziertes technisches Fundament. Gemeint ist ein verbindliches System aus Konventionen, wiederverwendbaren Bausteinen und klaren Erweiterungspunkten. Es sorgt dafür, dass Entwickler nicht in jeder Maske erneut über Fehlermeldungen, Navigation, Berechtigungen oder Benennungen nachdenken müssen.
Ohne Framework entsteht Architektur trotzdem, halt nur ungeplant
Auch eine Anwendung ohne offiziell definiertes Framework hat gemeinsame Muster. Sie sind dann lediglich verstreut: Ein Kollege unterdrückt Meldungen über :SYSTEM.MESSAGE_LEVEL, eine Entwicklerin baut ein eigenes Alert-Package, ein dritter kopiert einen Trigger aus einer alten Maske. Mit jeder Kopie entstehen neue Varianten. Fehlerkorrekturen müssen anschließend an vielen Stellen nachgezogen werden – oder bleiben inkonsistent.
Das Problem ist nicht, dass es Leute gibt, die den Code wiederverwenden. Das Problem ist, dass du mit Copy-and-paste die Herkunft eines Bausteins verschleierst. Ein Framework macht beides: Wo befindet sich die zentrale Implementierung, und wie wird sie von einer Maske verwendet?
Die fünf Bausteine eines praxistauglichen Forms-Frameworks
Mein ursprünglicher Ansatz beginnt mit drei Schritten: Styleguide definieren, Referenzform und Templates bereitstellen, anschließend Prototypen bauen. Für heutige Teams kannst du daraus ein Modell mit fünf Bausteinen ableiten:
1. Ein Styleguide beschreibt Entscheidungen, nicht Geschmack
Ein Forms-Styleguide sollte mehr enthalten als Farben, Schriftgrößen und Namenspräfixe. Wertvoll wird er dort, wo er das Laufzeitverhalten vereinheitlicht. Dazu gehören beispielsweise:
- Welche Trigger dürfen Logik enthalten, und welche delegieren nur an Packages?
- Wie werden Fehler klassifiziert, angezeigt und protokolliert?
- Wie werden Form-, Block- und Item-Namen gebildet?
- Welche Regeln gelten für Commit, Rollback, Exit und Navigation?
- Wie werden Berechtigungen und dynamische Menüs behandelt?
- Welche Logik gehört in die Maske, welche in eine PLL und welche in die Datenbank?
Ein guter Styleguide macht Code-Reviews kürzer. Du diskutierst dann nicht bei jeder Änderung in deinem Team dieselben Grundsatzfragen, sondern du prüfst, ob die vereinbarten Regeln korrekt angewendet wurden.
2. Die Referenzform zeigt den Sollzustand
Dokumentation allein reicht bei Forms selten aus. Besser ist eine Referenzform. Denn diese macht sichtbar, wie die Standards zusammenspielen: Welche Libraries sind angebunden? Welche Form-Level-Trigger existieren? Wie werden Alerts aufgerufen? Wie sehen Menüanbindung, Toolbar-Verhalten und Exception Handling aus?
Diese Form ist kein möglichst großes Demo-Modul, sondern ein ausführbares Architekturbeispiel. Sie sollte klein genug bleiben, damit neue Teammitglieder die Mechanik an einem Nachmittag nachvollziehen können. Gleichzeitig muss sie produktionsnah genug sein, um dir als Ausgangspunkt für neue Masken zu dienen.
3. Templates reduzieren Varianz
Ein Template spart dir nicht nur Klickarbeit. Sondern es setzt sichere Defaults. Neue Forms starten mit den richtigen Libraries, Triggern, Visual Attributes und Standardobjekten. Noch entscheidender ist jedoch die Pflege: Denn ein Template ist eine Momentaufnahme. Bereits erzeugte Masken übernehmen spätere Änderungen nicht automatisch. Deshalb braucht jede zentrale Funktion zusätzlich einen wiederverwendbaren Implementierungsort – meistens eine PLL oder ein Datenbank-Package.
4. Libraries bündeln Querschnittsfunktionen
In meinem Blog nenne ich hier unter anderem Exception Handling, dynamisches Meldungswesen, Zugriffsrechte, dynamische Menüs und PL/SQL-Libraries als Framework-Themen. Der gemeinsame Nenner: Es handelt sich um Funktionen, die viele Masken benötigen, deren Regeln aber nur an einer Stelle geändert werden müssen.
Wichtig: Eine Library sollte dabei nicht zu einem ungeordneten Sammelbecken werden. Besser sind klar abgegrenzte Packages, etwa für Navigation, Meldungen, Fehlerprotokollierung, Berechtigungsprüfung und technische Hilfsfunktionen. Denn so bleibt erkennbar, welcher Baustein wofür verantwortlich ist.
5. Prototypen prüfen nicht nur die Funktion, sondern das Framework
Ein Prototyp ist für dich besonders wertvoll, wenn er bewusst schwierige Fälle enthält: einen Multi-Record-Block, eine Master-Detail-Beziehung, Validierung mit Navigation, Datenbankfehler und einen Abbruch durch den Anwender. Erst an solchen Fällen zeigt sich, ob das Framework den Alltag erleichtert oder lediglich den einfachen Happy Path abdeckt.
Konstanten: Kleine Technik, große Wirkung
Eine der einfachsten und zugleich wirksamsten Regeln ist für mich die Trennung von Literalen und Logik. Namen von Alerts, Blöcken, Items, Statuswerten oder Navigationsmodi tauchen in Forms häufig als Strings auf. Werden diese Zeichenketten überall hart codiert, reicht ein Tippfehler für einen schwer auffindbaren Laufzeitfehler.
Deshalb schlage ich in meinen Trainings zwei Ebenen vor: ein globales Konstanten-Package in einer zentralen Library und ein lokales Package in jeder Formsmaske.
PACKAGE const IS alr_error CONSTANT VARCHAR2(30) := 'AL_ERROR'; alr_info CONSTANT VARCHAR2(30) := 'AL_INFO'; alr_warning CONSTANT VARCHAR2(30) := 'AL_WARNING'; sta_changed CONSTANT VARCHAR2(10) := 'CHANGED'; mod_open_form CONSTANT VARCHAR2(10) := 'OPEN_FORM'; END const;
Das globale Package enthält Konstanten, die in der gesamten Anwendung dieselbe Bedeutung haben. Maskenspezifische Namen bleiben lokal:
PACKAGE const_local IS blk_control CONSTANT VARCHAR2(30) := 'CONTROL'; itm_search CONSTANT VARCHAR2(61) := 'CONTROL.SEARCH_TEXT'; END const_local;
Der Aufruf wird dadurch lesbarer:
IF :SYSTEM.RECORD_STATUS = const.sta_changed THEN -- geänderten Datensatz behandeln END IF;
Der Nutzen geht über Lesbarkeit hinaus. Das heißt: Hast du den Namen einer Konstanten falsch geschrieben, meldet der Compiler den Fehler. Hat jemand hingegen den hinterlegten Stringwert falsch gepflegt, bleibt zwar weiterhin ein Laufzeitproblem möglich, aber die Ursache findest du an einem zentralen Ort und nicht in vielen Triggern. Diese Unterscheidung ist wichtig: Konstanten beseitigen also keine dynamische Namensauflösung von Forms, sie machen sie kontrollierbarer.
Was gehört global, was lokal?
Eine einfache Entscheidungsregel hilft:
- Global: fach- oder anwendungsweit identische Begriffe, gemeinsame Alerts, Statuswerte, Standardmodi und Framework-Ereignisse.
- Lokal: Block- und Item-Namen einer konkreten Form, form-spezifische Canvas- oder Window-Namen sowie lokale Ereigniscodes.
- Nicht als Konstante: Werte, die Administratoren konfigurieren sollen, Geheimnisse, Umgebungsparameter oder fachliche Regeln mit eigenem Lebenszyklus. Sie gehören in Konfigurationstabellen oder geeignete Services.
Ein Framework darf Entwicklung nicht verstecken
Ein Framework ist dann gelungen, wenn du die fachliche Absicht eines Triggers schneller erkennst. Ein WHEN-BUTTON-PRESSED, der eine klar benannte Navigationsroutine aufruft, ist verständlicher als zwanzig Zeilen wiederholte Status-, Fehler- und Fokuslogik. Problematisch wird es, wenn ein einziger vermeintlich komfortabler Aufruf unbemerkt Commit, Navigation, Berechtigungsprüfung und Meldungsunterdrückung kombiniert.
Deshalb sind bei Framework-Routinen drei Eigenschaften wichtig:
- Eindeutige Verantwortung: Der Name beschreibt die relevante Wirkung.
- Dokumentierte Vor- und Nachbedingungen: Darf die Routine validieren, navigieren oder Transaktionen beenden?
- Vorhersehbares Fehlerverhalten: Fehler werden entweder behandelt oder eindeutig an den Aufrufer zurückgegeben.
So startest du ohne Big Bang
Ein bestehendes Forms-System muss du nicht in ein Großprojekt umbauen. Stattdessen könnte ein pragmatischer Einstieg so aussehen:
- Du sammelst wiederholten Code und häufige Fehler aus mehreren repräsentativen Masken.
- Daraus leitest du wenige verbindliche Regeln für Deinen Styleguide und deren Namenskonventionen ab.
- Du erstellst eine kleine Referenzform mit den wichtigsten Objekten, die in jeder Maske benötigt werden.
- Querschnittsfunktionen verschiebst du zentral in Packages und Libraries.
- Zwei oder drei unterschiedlich komplexe Forms migrierst du als Pilot.
- Neue Standards führst du anschließend immer dort ein, wo eine Maske ohnehin geändert wird.
So wächst das Framework mit realen Anforderungen. Es bleibt überprüfbar und wird nicht zu einer theoretischen Plattform, die an deinem Alltag als Entwickler vorbeigeht.
Fazit: Einmal entscheiden, überall profitieren
Die zentrale Erkenntnis aus drei Jahrzehnten Forms-Praxis heißt für mich: Große Anwendungen bekommst du wartungsmäßig nicht durch einzelne geniale Trigger in den Griff, sondern durch wiederholbare Entscheidungen. Styleguide, Referenzform, Templates, Libraries und Konstanten bilden hierbei gemeinsam eine Plattform, die alle im Team nutzen können.
Das bedeutet im Klartext: Ein gutes Oracle-Forms-Framework nimmt dir nicht die Kontrolle. Es nimmt dir Wiederholungen ab. Dadurch hast du mehr Zeit für das, was in jeder Maske tatsächlich neu ist: die Fachlichkeit.
Links
Im Cattle Crew Blog: Oracle Forms 14: New Features Every Forms Developer Should Know
In meinem Blog Talk2Gerd:
Erstellen eines Forms Frameworks
Auf Github: Auf Github Historischer Quellstand des Forms-Framework-Projekts
Du brauchst eine Schulung?
5-tägige Oracle-Forms-Schulung für Unternehmen mit Gerd Volberg
