Das großartige, wenn man mit Oracle APEX arbeitet, ist dass es immer noch eine Menge an Pionierarbeit zu erledigen gilt. Oft gibt es Ansätze, die man erweitern kann, aber oft gibt es für bestimmte Probleme noch gar keine Lösung. Genau diese Art von Problemstellungen sind es doch, warum wir ursprünglich mal Softwareentwickler geworden sind. Weil wir es lieben zu tüfteln, zu knobeln, oder nach der Arbeit die Welt von einem bösen Zombiepiraten zu befreien.
Aber zurück zum Thema: In allen weit verbreiteten Programmiersprachen ist eine IDE mit Autovervollständigung der Standard. Der Vergleich mit Oracle APEX ist hier aber nicht hundertprozentig fair, weil APEX im eigentlichen Sinne keine Programmiersprache, sondern ein Framework ist. Die Bibliotheken, die wir bei der Entwicklung in APEX verwenden, liegen in der Oracle Datenbank. Diese brauchen wir, um APEX zu betreiben. Ihr merkt also schon, wir haben kein lokales class-File, dass wir parsen können oder keine lokalen Klassen. Unsere Klassen sind Packages die als kompilierter Code in einem Datenbankschema liegen.
Welche Tools stehen uns also als APEX Entwickler zur Verfügung?
Oracles SQL Developer oder Quests Toad sind bisher die beiden Tools, die mir zur Datenbankentwicklung am meisten begegnet sind. Beide haben ihre Vor- und Nachteile, auf die ich hier nicht weiter eingehen will. Aber eine vernünftige Autovervollständigung haben beide nicht!
Als nächstes wäre APEX selbst zu nennen. Ab Version 20.2 gibt es eine integrierte Autovervollständigung. Diese kennt aber „nur“ die APEX Packages und die Objekte die wir in unserem Parsing-Schema (die View Schicht einer APEX Anwendung) definieren. Das Problem hat eine weitere Dimension: Es gibt einen quasi Standard, der besagt, dass man Code innerhalb von APEX aus Performance-, und damit letztendlich User Experience-, gründen vermeiden soll. Der Code soll stattdessen in Form von Packages in der Datenbank gehalten werden.
Es scheint also als müssten wir uns zwischen zwei Alternativen entscheiden: entweder suboptimale Anwendungen in APEX bauen oder auf eine komfortable Entwicklungsumgebung verzichten.
Suboptimale Anwendungen zu entwickeln ist natürlich keine Alternative. Deshalb haben wir uns eine Best Practise Architektur geschaffen, die ich im Folgenden kurz beschrieben möchte, um damit die Problemstellung noch klarer zu machen.
Wie man in der Abbildung 1 sieht, schneiden wir unsere Anwendungsarchitektur, nach Vorbild des MVC Patterns, in drei Schichten:
Die DATA Schicht ist unsere Persistenz und enthält alle Entitäten unserer Anwendung.
Die LOGIC Schicht enthält die gesamte Anwendungslogik und übernimmt den Transport und die Aufbereitung von Daten von der DATA zur APP-Schicht.
Die APP Schicht ist unser APEX Parsing Schema und übernimmt Aufgaben, die sich auf das Frontend beziehen wie Validierungen, Datenpräsentation etc. Insbesondere auf dieser Ebene wird immer wieder auf Objekte der LOGIC Schicht, auf 3rd Party Libraries oder auf APEX native Objekte zugegriffen.
Um uns also die Arbeit in der APP-Schicht zu erleichtern brauchen wir ein Tool, dass:
- APEX Packages, APEX Variablen (Page Items),
- Objekte der LOGIC Schicht auf welche die APP-Schicht Zugriff hat,
- 3rd Party Libraries die auf der APP-Schicht zum Einsatz kommen
kennt und uns beim coden als Vorschläge zur Autovervollständigung anbietet.
APEX meet Visual Studio Code, Visual Studio Code meet APEX
Die Möglichkeit das zu verwirklichen ist eine Visual Studio Code Extension, ApexIntelliSense!
Visual Studio Code hat sich, aufgrund der guten Erweiterbarkeit durch Extensions, in den letzten Jahren bei uns zu einem de facto Standard entwickelt. Die ApexIntelliSense-Extension bietet die Möglichkeit sich mit einem APEX Parsing Schema zu verbinden. Dabei werden dann alle oben genannten Objekte ausgelesen und in einem Cache gespeichert, der auf Wunsch aktualisiert werden kann. Der Cache wird in Form von yaml-Dateien vorgehalten, die sich gut in eine Versionierung einbinden lassen.
Es werden zwei yaml-Cache-Files aufgebaut:
- eine für Parsing-Schema Objekte
- eine für APEX Objekte
Ein Feature der Extension ist, dass ein bereits erstellter APEX Cache als Quelle angegeben werden kann. Die Datei kann also zentral abgelegt werden und in mehrere Workspaces in Visual Studio Code eingebunden werden. Die Extension steht im Marketplace kostenlos zur Verfügung und kann bequem in Visual Studio Code installiert werden.
Es sei hier explizit erwähnt, dass unsere oben vorgestellt „Best Practise Architektur“ keine Voraussetzung für die Nutzung der Extension ist.
Demo
