Plugins für APEX programmieren

Was soll die Plugin-Programmierung?

Das Ziel der Plugin-Programmierung ist, Erweiterungen der APEX-Bausteine zu erstellen, die ebenso intuitiv genutzt werden können sollen wie die eingebauten APEX-Bausteine. Unter dem Begriff APEX-Bausteine verstehe ich hier Regions, Items, Dynamic Actions, Authentication/Authoraization Schemes, und Processes. All diese Typen können durch Plugins erweitert werden. Plugins können zudem einfach in der Community verteilt und so von vielen APEX-Entwicklern genutzt werden (Beispiele finden Sie hier).

Ich möchte zunächst einmal erläutern, warum der Plugin-Mechanismus nicht nur interessant ist, wenn Sie ein Plugin mit anderen APEX-Entwicklern global teilen möchten, sondern auch für lokale Projekte äußerst hilfreich ist. APEX bietet mit der Plugin-Erweiterung eine Standardschnittstelle, um eine neue Funktionalität in APEX zu kapseln und in die Entwicklungsumgebung zu integrieren. Da ein Plugin in die Entwicklungsumgebung integriert ist und von dieser aus aufgerufen und über die Definition eigener Plugin-Parameter auch parametriert werden kann, der Plugin-Mechanismus zudem noch das Laden der zugehörigen JavaScript-, CSS und Bilddateien übernehmen kann, sorgt das Plugin für eine sehr gute Kapselung der Funktionalität sowie für aufgeräumte APEX-Seiten.

Der Entwickler des Plugins muss zudem nicht mit dem Entwickler der APEX-Seite identisch sein, so dass diesem zum Beispiel die Niederungen der JavaScript bzw. JQuery-Programmierung abgenommen werden. Der Entwickler einer Seite verwendet einfach ein erstelltes Plugin, parametriert es und braucht sich um die Implementierung nicht zu kümmern.

Direkt zu Beginn: Eine Warnung!

Ein Nachteil der Plugin-Programmierung soll jedoch gleich zu Beginn angesprochen werden: Die Entwicklungszeit eines Plugins ist deutlich zeitaufwändiger als die Verwendung der eingebauten Standardfunktionalität. Hier können Sie ohne weiteres (eher: mindestens) den Faktor 10 ansetzen. Sie müssen, gerade in der ersten Phase der Entwicklung eines Plugins, mit häufigen Redefinitionen und dem damit verbundenen Aufwand rechnen. Zudem erschwert die Verwendung eines Plugins die Einarbeitung eines neuen Teammitglieds, denn die Spezifika der Verwendung eines Plugins müssen zusätzlich gelernt werden. Hier zahlt sich eine saubere Programmierung und eine gute Dokumentation besonders aus, doch bleibt als Zusammenfassung festzuhalten: Versuchen Sie in jedem Fall, so lange wie möglich mit der Standardfunktionalität von APEX auszukommen. Plugins verwenden Sie, wenn Sie müssen, nicht, weil Sie ein bestimmtes Verhalten der Oberfläche einfach hübscher fänden (es sei denn, Sie werden ausschließlich nach Times & Material bezahlt und müssen diese totschlagen :-).

In einigen Projekten habe ich zudem eine Vorliebe für bereits fertig angebotene Plugins, zum Beispiel von der oben angesprochenen Seite, kennengelernt. Doch auch hier möchte ich warnen: Es gibt keine Qualitätskontrolle dieser Plugins außer durch ein Rating der mehr oder minder begeisterten Benutzer. Zudem stellt sich zumeist im Verlauf des Projektes heraus, dass ein Plugin doch nicht genau das tut, was es soll. Es ist häufig extrem aufwändig, sich in die Programmierung eines Plugins einzulesen, um es dann an die eigenen Bedürfnisse anzupassen. Und schließlich ist der Programmierstil der Plugins, inklusive der Definition Plugin-Parametern, die Einbindung in den APEX-Kontext etc. stark unterschiedlich gut gelöst, so dass sich ein Flickenteppich unterschiedlicher APIs ergeben kann, der sehr aufwändig zu pflegen ist.

Arbeitsweise eines Plugins

Ich beziehe mich zunächst auf die häufigsten Plugin-Arten, nämlich auf Region- oder Item-Plugins. Ein solches Plugin besteht zumeist aus einem PL/SQL-Logik sowie zusätzlichem JavaScript-Code und flankierenden Dateien, wie zum Beispiel CSS-Dateien und Bildern. All diese Elemente werden durch den Plugin-Mechanismus von APEX zusammengehalten. In den weiteren Teilen dieses Blogs werde ich mich um diese Bestandteile näher kümmern und Ihnen einige Best Practices für diese Bestandteile mitgeben (die natürlich immer zum Teil Geschmacksache sind).

Zu Beginn konzentriere ich mich jedoch auf die grundlegende Arbeitsweise eines solchen Plugins. Der Lebenszyklus startet damit, dass Sie ein Plugin auf einer APEX-Seite platzieren und mit den Parametern, die im Plugin deklariert sind, parametrieren. Wird die Seite nun aufgerufen, ist zunächst eine PL/SQL-Methode dafür zuständig, den HTML-Code, der für die Darstellung des Plugins auf der Seite benötigt wird, zusammen zu stellen und auszuliefern (Render-Phase). Diese Prozedur schreibt daher normalerweise HTML-Code in den HTTP-Stream. Der Plugin-Mechanismus bietet zudem noch Funktionen, um JavaScript- oder CSS-Dateien auszuliefern, die ebenfalls in dieser Prozedur aufgerufen werden. Zudem wird typischerweise noch lokal im Package JavaScript zusammengestellt, der für die Parametrierung des JavaScript-Teils eines Plugins verantwortlich ist. Hier können Sie sich zum Beispiel vorstellen, dass dieser JavaScript-Code ein JQuery Widget aufruft und dies an ein vorher von Ihnen ausgegebenes DOM-Element bindet.

Nun wird auf der Seite diese Region oder dieses Item mit der neuen Funktionalität erscheinen und dem Benutzer zur Verfügung stehen. Während der Darstellung auf der Seite kann nun, zum Beispiel durch eine Dynamic Action, ein Refresh dieses Plugins ausgelöst werden. Hierfür wird dann eine weitere Methode in PL/SQL aufgerufen, die dann die entsprechenden Aktivitäten durchführt (Refresh-Phase). Im Fall eines Item-Plugins ist zudem möglich, dass dieses Plugin beim Submit validiert wird. In diesem Fall wird wiederum eine Methode in PL/SQL aufgerufen, in der dann Validierungslogik hinterlegt werden kann.

Auf Grund dieser Arbeitsweise wird klar, dass ein Plugin an verschiedenen Stellen Logik benötigt:

  • In PL/SQL werden die datenbezogenen Arbeiten durchgeführt und der HTML-Code vorbereitet, und zwar sowohl beim initialen Erzeugen, als auch beim späteren Refresh. Zudem werden benötigte JavaScript- und CSS-Dateien eingebunden sowie der initial auszuführende JavaScript-Code erstellt.
  • In JavaScript wird die Einbindung der Client-seitigen Funktionalität in das Umfeld von APEX vorgenommen. Die Aufgabe ist hier nicht nur, ein JQuery-Plugin (oder was immer Sie sonst mögen) einzubinden, sondern auch, AJAX-Calls abzusetzen oder die Plugin-Events (zum Beispiel before- bzw. afterApexRefresh) zu implementieren
  • Schließlich bleibt die Aufgabe, die eigentliche Funktionalität zu programmieren. Auf Grund der Entscheidung des APEX-Teams, JQuery als JavaScript-Framework zu verwenden, wird es sich hierbei häufig um die Integration von JQuery-UI-Widgets oder JQuery-Plugins handeln.

Leider haben alle diese Bausteine verschiedene Anforderungen an den Programmierstil, daher ist die Erstellung eines "sauberen" Plugins alles andere als trivial. Nehmen wir ein Plugin, das ein JQuery-UI-Widget in eine APEX Anwendung integriert. Das UI-Widget wird von Ihnen selbst programmiert. Dann befolgen Sie am Besten die Programmierrichtlinien der JQuery-UI-Widget Factory, um sicher zu stellen, dass auch andere Entwickler Ihr Widget verstehen und warten können und um die Funktionalität dieser Factory nutzen zu können. Zur Integration eines JQuery-UI-Widgets in das APEX-Umfeld gibt es einige Beispiele des APEX-Teams selbst, die dann die entsprechenden APEX-Namensräume, zum Beispiel für AJAX-Aufrufe etc. nutzen. Es empfiehlt sich, diesen Teil des Codes den dort vorgegebenen Richtlinien anzupassen. Schließlich ist noch ein Plugin-Package in PL/SQL zu erstellen, dass mehrere Methoden implementieren muss, die der Plugin-Mechanismus vorgibt. Daher empfiehlt es sich, diese Packages an den Beispielen von Patrick Wolf bzw. dem APEX-Team auszurichten.

Noch nicht tangiert wurden die Probleme, die sich durch mehrere Instanzen eines Plugins auf einer Seite ergeben. Zudem verstößt sowohl das APEX-Team als auch viele Plugin-Entwickler aus dem Umfeld von JQuery gegen diese Kodierrichtlinien, so dass ein buntes Sammelsurium verschiedener Stile, Konventionen etc. die Folge ist. Nehmen Sie nun noch die dürftige Dokumentationslage hinzu, und Sie haben die idealen Voraussetzungen für ein Programmierdesaster.

Die nächsten Blogs werden versuchen, ein wenig Licht in dieses Durcheinander zu bringen. 

Kommentar schreiben


Sicherheitscode
Aktualisieren