Oracle Forms: How to create a Framework

996 Aufrufe

Veröffentlicht am

http://www.opitz-consulting.com/go/3-4-11

Größere Oracle Forms Applikationen sind nicht denkbar ohne den Einsatz von Frameworks. Im einfachsten Fall sind es ein paar selbst geschriebene Libraries, die man in seiner Applikation nutzt. Auf der anderen Seite des Spektrums steht der Einsatz von PL/SQL- und Objekt-Libraries, Referenztemplates und Datenbank-API’s. Entwicklungs-Handbücher, z.B. für einen Style Guide, Namenskonventionen oder eine Versionierungsdokumentation, sollten ebenfalls nicht fehlen.

In seinem Vortrag bei der DOAG Konferenz 2014 beschrieb unser Forms Experte Gerd Volberg, wie man alle diese Teile eines Frameworks selbst konzipieren kann, worauf man achten sollte und wie man ggf. ein neues Framework in eine bestehende Forms Landschaft integrieren kann. Source-Code-Beispiele illustrierten dabei jeden einzelnen Bereich und wurden zusammen mit der Vortragsdokumentation auf der offiziellen Konferenz-Website veröffentlicht.

--
Über uns:
Als führender Projektspezialist für ganzheitliche IT-Lösungen tragen wir zur Wertsteigerung der Organisationen unserer Kunden bei und bringen IT und Business in Einklang. Mit OPITZ CONSULTING als zuverlässigem Partner können sich unsere Kunden auf ihr Kerngeschäft konzentrieren und ihre Wettbewerbsvorteile nachhaltig absichern und ausbauen.

Über unsere IT-Beratung: http://www.opitz-consulting.com/go/3-8-10
Unser Leistungsangebot: http://www.opitz-consulting.com/go/3-8-874
Karriere bei OPITZ CONSULTING: http://www.opitz-consulting.com/go/3-8-5

Veröffentlicht in: Technologie
0 Kommentare
0 Gefällt mir
Statistik
Notizen
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

Keine Downloads
Aufrufe
Aufrufe insgesamt
996
Auf SlideShare
0
Aus Einbettungen
0
Anzahl an Einbettungen
3
Aktionen
Geteilt
0
Downloads
0
Kommentare
0
Gefällt mir
0
Einbettungen 0
Keine Einbettungen

Keine Notizen für die Folie

Oracle Forms: How to create a Framework

  1. 1. How to create a Framework © OPITZ CONSULTING GmbH Seite 1 Gerd Volberg OPITZ CONSULTING Deutschland GmbH Nürnberg, 18. November 2014
  2. 2. © OPITZ CONSULTING GmbH Seite 2 Agenda 1. Wofür braucht man ein Framework? 2. Style Guide 3. Programmiervorschriften 4. Layout-Vorschriften 5. Namenskonventionen 6. Templates + Vererbungsstrategien 7. Demos
  3. 3. 1 Wofür braucht man ein Framework? © OPITZ CONSULTING GmbH Seite 3
  4. 4. Wofür braucht man ein Framework? 1. Corporate Design durch einheitliches Look & Feel 2. Programmier-Vorgaben für das Entwickler-Team  Programmiervorschriften  Layout-Konventionen  Namenskonventionen  Interaktion mit der Datenbank (Surrogate Keys, API‘s, …) 3. Templates und Libraries vereinfachen und verkürzen die © OPITZ CONSULTING GmbH Seite 4 Entwicklungsphase 4. Bessere Wartbarkeit der Applikation
  5. 5. © OPITZ CONSULTING GmbH Seite 5 2 Style Guide
  6. 6. Style Guide 1. Der eigene, firmenweit gültige Style Guide ist die Bibel einer unternehmensweiten Softwareentwicklung. 2. Im Style Guide werden alle Themen beschrieben, die während des Software-Erstellungsprozesses und darüber hinaus in der Wartungsphase relevant sind. © OPITZ CONSULTING GmbH Seite 6
  7. 7. Style Guide – Primary Keys 1. Tabellen in einer relationalen DB benötigen Primary Keys. Diese sollten immer mit der gleichen Technik erzeugt und eingesetzt werden: © OPITZ CONSULTING GmbH Seite 7 2. Sprechende Schlüssel  Sind meistens abgeleitet aus den eindeutigen Attributen einer Tabelle.  Bestehen oft aus mehreren Attributen (Verbundschlüssel).  Vorteile: Gut lesbar, da sie aus relevanten Tabellendaten bestehen. 3. Surrogate Keys  Der Primary Key besteht aus einer Spalte (Sequenzen befüllen ihn).  Der PK hat keinen Bezug zu den Daten seiner Tabelle.  Vorteile: Der PK ist nicht änderbar, hat eine optimale Indizierung und ist sehr einfach nutz- und referenzierbar
  8. 8. © OPITZ CONSULTING GmbH Seite 8 Style Guide – Surrogate Keys  Surrogat-Key  Jede Tabelle bekommt einen festen ALIAS aus 4 Buchstaben  Primary Key => ALIAS + "_ID"  Foreign Key => Primary Key der Fremdtabelle
  9. 9. © OPITZ CONSULTING GmbH Seite 9 3 Programmiervorschriften
  10. 10. © OPITZ CONSULTING GmbH Seite 10 Programmiervorschriften (1) Alle Regeln, die im Team gelten sollen, müssen definiert werden und sollten niemals verletzt werden. Z.B.  GOTO – verboten - Wer trotzdem mit GOTO arbeiten möchte, kann ja in BASIC weiterarbeiten  LABEL – verboten (wenn sie als Sprungmarke genutzt werden)  RETURN – nur in Funktionen erlaubt  EXIT – in Loops verboten - Loops schreibt man besser immer mit einem beginnenden FOR oder WHILE  TAB – verboten. Zur Einrückung immer 2 Leerzeichen pro Ebene
  11. 11. © OPITZ CONSULTING GmbH Seite 11 Programmiervorschriften (2) Web-Regeln  Keine ActiveX, OCX, OLE, VBX einsetzen (Stattdessen Java-Beans)  Keine WHEN-MOUSE-ENTER/LEAVE/MOVE – Trigger Richtlinien  Hochfrequente Timer sollten nicht verwendet werden  Die Netzwerkverbindungen sollten optimiert werden  Datenbankabfragen sollten so effizient wie möglich formuliert werden und optimalerweise in einem API in der Datenbank liegen
  12. 12. © OPITZ CONSULTING GmbH Seite 12 4 Layout-Vorschriften
  13. 13. Layout-Vorschriften (1) 1. Hierunter fallen zum Beispiel die Definition einer Standard- Grösse für alle Formsmasken. Z.B. 1280*1024, 1680*1050… 2. Neben den Runtime-Einstellungen sollten auch die Designtime-Einstellungen verbindlich definiert werden. © OPITZ CONSULTING GmbH Seite 13  Ruler-Settings
  14. 14. © OPITZ CONSULTING GmbH Seite 14 Layout-Vorschriften (2)  Grid einschalten, Show Canvas ausschalten Dadurch wird der Layout Editor optimal benutzbar:  Standardabstände  X-Richtung: 6  Y-Richtung: 18
  15. 15. © OPITZ CONSULTING GmbH Seite 15 5 Namenskonventionen
  16. 16. © OPITZ CONSULTING GmbH Seite 16 Namenskonventionen (DB) Benamung von Objekten in der Datenbank ist sehr wichtig. Hier sollten strengste Konventionen gelten. Objekt Notation Tabelle <28 Zeichen> Sprechender Name. Tabellennamen immer Plural. Primary Key <TabellenAlias> _ID Vierstelliger eindeutiger Alias des Tabellennamens. Foreign Key (1) <ReferenzAlias> _ID <ReferenzAlias> ist der Alias der Referenz-Tabelle. Foreign Key (2) <ReferenzAlias> "_“ <22 Zeichen> _ID Mehrfachreferenz auf die gleiche Tabelle. Foreign Key (3) <TabellenAlias> "_“ <Primary Key> Selbstreferenz auf die eigene Tabelle. Tabellen-Spalte <25 Zeichen> Sprechender Name, 25 Zeichen max. wg View-Spalten innerhalb einer Tabelle. View <TabellenName> _V View, die auf einer Tabelle aufbaut (Standard-View). View <TabellenName>[x] _V Mehrere Views auf der gleichen Tabelle. View <28 Zeichen> _V Der Name der View beinhaltet mindestens den Namen der wichtigsten Tabellen, die benutzt werden. View <27 Zeichen>[x] _V Bei mehreren Views, die auf die gleichen Tabellen schauen. View-Spalte <TabellenAlias> "_" <Tabellen-Spalte> Der Name einer View-Spalte setzt sich aus dem Alias der zugehörigen Tabelle und dem Originalnamen der Spalte in dieser Tabelle zusammen. Damit sind die Spalten der View immer eindeutig. Sequence <TabellenAlias> _SEQ Die Standard-Sequence jeder Tabelle setzt sich aus dem Tabellen-Alias und "_SEQ" zusammen
  17. 17. © OPITZ CONSULTING GmbH Seite 17 Namenskonventionen  Am Beispiel einer Auftrags- und Positionen-tabelle wird hier nun exemplarisch gezeigt, wie Namenskonventionen aussehen könnten  Alle Themenbereiche, in denen Konventionen benötigt werden, kommen auf den nächsten Seiten
  18. 18. © OPITZ CONSULTING GmbH Seite 18 Namenskonventionen (DB) Interne Benamungen in der DB Objekt Notation Tabellen-Alias <4 Zeichen> Abkürzung der Tabelle (Unique über alle Projekte) Primary Key <Alias> _PK Foreign Key <Alias_von>_<Alias_nach> _FK Foreign Key <Alias_von>_<Alias_nach> _ [x] _FK Falls mehrere benötigt werden => durchnummerieren Unique Key <Alias> _UK Bei einem Unique-Key Unique Key <Alias> _ [x] _UK Falls mehrere benötigt werden => durchnummerieren Check Constraint <Alias> _CHK Bei einem Check Constraint Check Constraint <Alias> _ [x] _CHK Bei mehreren Index <Alias> _I Bei einem Index Index <Alias> _ [x] _I Falls mehrere benötigt werden => durchnummerieren DB-Trigger <Alias> _[A|B] [R|S] [<I> <U> <D>] A – After; B – Before R – Row; S – Statement I – Insert; U – Update; D – Delete
  19. 19. © OPITZ CONSULTING GmbH Seite 19 Namenskonventionen (Forms) Objekt Präfix Forms-Objekte Blöcke Kein Präfix, sprechender Name Alert AL_ Canvas CN_ Editor ED_ Frame FR_ LOV LV_ Object Group OG_ Parameter PA_ Popup Menu PM_ Property Class PC_ Record Group RG_ Visual Attribute (Common) VA_ Visual Attribute (Prompt) VP_ Visual Attribute (Title) VT_ Window WN_ User Named Trigger UN_
  20. 20. © OPITZ CONSULTING GmbH Seite 20 Namenskonventionen (Forms) Objekt Präfix Item-Typen Bean Area BA_ Button BT_ Button-LOV BT_LV_ Checkbox CB_ Chart Item CI_ Display Item DI_ Hierarchical Tree HT_ Image IM_ List Item LI_ OLE-Container OC_ Radio Group RA_ Radio Button RB_ Sound SO_ Text Item TI_ User Area UA_
  21. 21. © OPITZ CONSULTING GmbH Seite 21 Namenskonventionen (PL/SQL) PL/SQL-Präfixe Objekt Notation Constant Variable C_ Cursor Cur_ Parameter P_ Recordvariable R_ Typ T_ Variable V_
  22. 22. © OPITZ CONSULTING GmbH Seite 22 Sourcecode-Layout 1. Einrückung  z.B. 2 Leerzeichen pro Ebene und niemals Tabs 2. Groß / Kleinschreibung  Reservierte Worte werden groß geschrieben, alle anderen Worte Initcap 3. Leerzeichen bei Parameterübergabe  Vor jeder Klammer und hinter jedem Komma ein Leerzeichen  Vor und hinter jeder Zuweisung ein Leerzeichen 4. Aliasnutzung beim Select auf mehrere Tabellen  Wenn in einem Select die FROM-Clause mehr als eine Tabelle benutzt, sollte jede Tabelle mit einem Alias versehen werden. Aliase wie im Kapitel „Interne Benamungen in der DB“ 5.
  23. 23. © OPITZ CONSULTING GmbH Seite 23 Sourcecode-Formatierung Alle relevanten Strukturen in PL/SQL sollten definiert werden SELECT Auftrag_Nr, Datum FROM Auftraege WHERE Auftrag_ID = V_Auftrag_ID AND Datum > SYSDATE – 10 ORDER BY Auftrag_Nr; UPDATE Auftraege SET Kunden_Name = 'Müller' WHERE AUFT_ID = V_AUFT_ID; DELETE FROM Positionen WHERE Datum < Sysdate – 180; INSERT INTO Positionen (POSI_ID, AUFT_ID, Position_Nr, Datum, Anzahl, Wert) VALUES (V_POSI_ID, V_AUFT_ID, 1, SYSDATE, 17, 12.50);
  24. 24. © OPITZ CONSULTING GmbH Seite 24 Exception-Handling In jeder Routine muss am Ende ein Exception-Handling geschrieben werden. Beispiel: EXCEPTION WHEN <Exception> THEN Statement1; WHEN OTHERS THEN Statement2; END;
  25. 25. Kommentare (1) 1. Ein effektiver Code-Stil hat zum Ziel, verständlichen, produktiven und wartbaren Code zu erzeugen. Die meisten Programme profitieren von den im Programm dokumentierten Kommentaren und Erklärungen. 2. Diese Kommentare erhöhen die Lesbarkeit des Source- Codes enorm. Entwickler, die den Source-Code in der Wartungsphase das erste Mal zu sehen bekommen, haben meist keine Chance, den Code zu verstehen, ohne eine gute Inline-Dokumentation. © OPITZ CONSULTING GmbH Seite 25
  26. 26. © OPITZ CONSULTING GmbH Seite 26 Kommentare (2) 1. Tipps zum Schreiben von Kommentaren  Schreibe Source-Code geradeaus und ohne Tricks und Kniffe  (egal, wie gut diese dokumentiert sind)  Variablen, Module und andere Namen bekommen sprechende Namen  (egal, wie lang sie sind)  Nutze immer Konstanten statt Literale  (sowohl als Übergabewerte, wie auch als Vergleichswerte oder an anderen Stellen)  Arbeite immer mit den gleichen, sauberen und durchgängigen Sourcecode- Layout-Regeln  Kommentiere den Source-Code während Du ihn schreibst.
  27. 27. 6 Templates + Vererbungsstrategien © OPITZ CONSULTING GmbH Seite 27
  28. 28. © OPITZ CONSULTING GmbH Seite 28 Templates  frw_ref frw_lib  frw_template  Applikation
  29. 29. Templates kontinuierlich weiterentwickeln  Templates sind in Funktion und Anzahl nicht begrenzt  Im Projektverlauf macht es Sinn kontinuierlich weitere Templates zu erzeugen, die vielleicht erst später benötigt werden © OPITZ CONSULTING GmbH Seite 29  Tree-Templates  Shuttle-Templates  …
  30. 30. © OPITZ CONSULTING GmbH Seite 30 Vererbungsstrategie Beispiel eines Referenz- Templates mit den wichtigsten Property- Klassen, Visual Attributes uvm.
  31. 31. Library Integration und PLL- vs. PLX-Nutzung  Reihenfolge, in der Forms seine Libraries nutzt: © OPITZ CONSULTING GmbH Seite 31  frw_lib.plx im Arbeitsverzeichnis  frw_lib.plx im FORMS_PATH  frw_lib.pll im Arbeitsverzeichnis  frw_lib.pll im FORMS_PATH  Ansonsten Fehlermeldung  Gleiches gilt für Forms und Menüs
  32. 32. © OPITZ CONSULTING GmbH Seite 32 Konstantenpackages  Zentrales Konstantenpackage  PACKAGE Const  Lokales Konstantenpackage  PACKAGE Const_local
  33. 33. © OPITZ CONSULTING GmbH Seite 33 Konstantenpackage Const PACKAGE Const IS -- Alerts alr_Error CONSTANT VARCHAR2 (30) := 'AL_ERROR'; alr_Info CONSTANT VARCHAR2 (30) := 'AL_INFO'; alr_Warning CONSTANT VARCHAR2 (30) := 'AL_WARNING'; -- Block, Record and Form-Status sta_Changed CONSTANT VARCHAR2 (10) := 'CHANGED'; sta_Insert CONSTANT VARCHAR2 (10) := 'INSERT'; sta_New CONSTANT VARCHAR2 (10) := 'NEW'; sta_Query CONSTANT VARCHAR2 (10) := 'QUERY'; -- Other CR CONSTANT VARCHAR2 (1) := CHR (10); Tab CONSTANT VARCHAR2 (1) := CHR (9); TRUE CONSTANT VARCHAR2 (10) := 'TRUE'; FALSE CONSTANT VARCHAR2 (10) := 'FALSE'; END Const;
  34. 34. © OPITZ CONSULTING GmbH Seite 34 Hilfsfunktionen (1)  Nachricht als Alert ausgeben  PROCEDURE Info  Parameter: P_Text IN VARCHAR2  Nachricht + Raise Form_Trigger_Failure  PROCEDURE Raise_Info  Parameter: P_Text IN VARCHAR2
  35. 35. © OPITZ CONSULTING GmbH Seite 35 Hilfsfunktionen (2)  Rückfrage stellen  FUNCTION Question  Parameter: P_Text IN VARCHAR2  Rückgabewert: NUMBER
  36. 36. © OPITZ CONSULTING GmbH Seite 36 Hilfsfunktionen (3)  Deutscher Wochentag ermitteln  FUNCTION German_Weekday  Parameter: P_Date IN DATE  Rückgabewert: NUMBER
  37. 37. © OPITZ CONSULTING GmbH Seite 37 7 Demos
  38. 38. © OPITZ CONSULTING GmbH Seite 38 One Time Timer
  39. 39. © OPITZ CONSULTING GmbH Seite 39 Undo
  40. 40. © OPITZ CONSULTING GmbH Seite 40 Multi LOV
  41. 41. © OPITZ CONSULTING GmbH Seite 41 Generische List-Items
  42. 42. © OPITZ CONSULTING GmbH Seite 42 LOV's mit gruppierten Daten
  43. 43. © OPITZ CONSULTING GmbH Seite 43 BI Beans
  44. 44. © OPITZ CONSULTING GmbH Seite 44 Ihr Ansprechpartner Gerd Volberg Solution Architect OPITZ CONSULTING Deutschland GmbH Kirchstr. 6, 51647 Gummersbach Tel. +49 (2261) 60 01-0 gerd.volberg@opitz-consulting.com talk2gerd.blogspot.com

×