Eine Hierarchie von Standardbuilddeskriptoren macht den Generierungsprozess flexibler.
Sie können Standardbuilddeskriptoren auf folgenden Ebenen angeben:
- Workbench
- Projekt
- Quellenordner
- Paket
- EGL-Quellendatei
Informationen dazu, wie die Builddeskriptoren angegeben werden, finden Sie unter Standardbuilddeskriptoren definieren.
Hierarchie der Standardbuilddeskriptoren
Alle
EGL-Generierungsoperationen verwenden den Standardbuilddeskriptor, der für den zu generierenden Abschnitt angegeben wurde. Es sei denn, Sie überschreiben den Standardbuilddeskriptor mithilfe des Assistenten für Generierung. Um den Assistenten für Generierung zu verwenden, klicken Sie mit der rechten Maustaste auf eine EGL-Quellendatei und dann auf Mit Assistenten generieren.
Um den zu verwendenden Standardbuilddeskriptor festzulegen, startet EGL mit der Suche bei der Quellendatei des Abschnitts, der generiert wird. Anschließend folgt EGL der Dateistruktur aufwärts, bis die erste Instanz eines Builddeskriptors gefunden wurde.
Wenn Sie ein Projekt erstellen, stellt EGL die Builddatei
projectName.eglbld zur Verfügung und definiert mindestens einen Builddeskriptorabschnitt innerhalb dieser Datei.
Für jeden Projekttyp gibt EGL einen bestimmten Standardbuilddeskriptor aus dieser Datei als Standardbuilddeskriptor auf Projektebene an:
- Für ein Rich UI-Projekt gibt EGL den JavaScriptBuildOptions-Builddeskriptorabschnitt projectName an.
- Für ein allgemeines Projekt hängt der Builddeskriptorabschnitt, den EGL angibt, von der Ziellaufzeitplattform ab, die Sie auswählen, wenn Sie das Projekt erstellen.
- Für Java™, projectNameJavaBuildOptions
- Für COBOL, projectNameCOBOLBuildOptions
- Für ein Web- oder Plug-in-Projekt gibt EGL den Builddeskriptorabschnitt projectNameJavaBuildOptions an
Anmerkung: Obwohl EGL zuerst diese Standardwerte angibt, können Sie sie löschen. Wenn Sie sie löschen und keine angepassten Builddeskriptoren auf einer untereren Ebene angeben, muss EGL die Workbench-Ebene (Vorgaben) nach einer Lösung durchsuchen. Wenn Sie keine Standardbuilddeskriptoren auf Workbenchebene angegeben haben, tritt ein Fehler auf und die Generierung schlägt fehl.
Weitere Informationen dazu, wie EGL Standardbuilddeskriptoren auflöst, sowie weitere Beispiel finden Sie unter "Builddeskriptoren, Zielplattformen und Debugger" in diesem Abschnitt.
Builddeskriptoren, Zielplattformen und Debugger
Sie können verschiedene Builddeskriptoren für unterschiedliche Situationen angeben.
Es gibt zwei Kategorien von Standardbuilddeskriptoren:
Geben Sie für das Debuggen andere Standardbuilddeskriptoren auf Grundlage des Anwendungstyps an, den Sie entwickeln:
- EGL verwendet den Debugger mit der Option Interpretierend für Abschnitte, die für Java oder
COBOL generiert wurden. Dieser Debugger arbeitet mit einer Interpretation des EGL-Quellcodes.
- EGL verwendet den Debugger mit der Option JavaScript für Abschnitte, die für JavaScript generiert wurden.
Dieser Debugger arbeitet, indem der generierte Code in einem Browser ausgeführt wird.
Geben Sie verschiedene Standardbuilddeskriptoren auf Grundlage der Zielplattformen an, für die Sie Ihren EGL-Code generieren können:
Innerhalb einer Kategorie werden alle Werte auf einer bestimmten Ebene verwendet, wenn ein beliebiger Wert auf dieser Ebene angegeben wurde. Diese Regel bedeutet Folgendes: Wenn EGL in der Zielplattformkategorie nach einem Builddeskriptor sucht und eine Übereinstimmung auf einer bestimmten Ebene findet, dann sucht EGL nicht weiter nach Builddeskriptorabschnitten auf höheren Ebenen.
Beispiel 1: Bibliothek für Client und Server generieren
Sie können dieselbe Bibliothek für Java und für JavaScript generieren, so dass die Bibliothek im Client und im Server ausgeführt werden kann. Hier folgt ein Beispiel für ein Rich UI-Projekt:
UIProject <- JavaScript default build descriptor (system)
EGLSource
handlers
MyHandler.egl
libraries
MyLibrary.egl
UIProject.eglbld
...
Da dieses Projekt für Rich
UI angepasst ist, gibt EGL einen Standardbuilddeskriptor für die Zielplattform JavaScript auf Projektebene an, wenn Sie das Projekt erstellen. Um sowohl die Java- als auch die JavaScript-Generierung
für MyLibrary.egl zu ermöglichen, geben Sie sowohl einen Java- als auch JavaScript-Standardbuilddeskriptor für die Bibliothek an.
Die folgende Anzeigenerfassung zeigt diese Builddeskriptorabschnitte, die als Eigenschaften für den Ordner
libraries angegeben wurden, der die Datei
MyLibrary.egl enthält. Sie müssen beide Angaben machen, da die Regel gilt, dass alle Werte auf einer bestimmten Ebene verwendet werden, wenn ein beliebiger Wert angegeben wurde.
Hier finden Sie eine aktualisierte Auflistung der Projektinhalte:
UIProject <- JavaScript default build descriptor (system)
EGLSource
handlers
MyHandler.egl
libraries <- Java and JavaScript default build descriptors (user)
MyLibrary.egl
UIProject.eglbld
...
EGL löst die Standardbuilddeskriptoren wie folgt auf:
- Für die Bibliothek MyLibrary.egl beginnt EGL mit der Quellendatei und folgt der Verzeichnisstruktur aufwärts, bis die Paketebene erreicht ist. Auf dieser Ebene findet EGL angepasste Standardbuilddeskriptoren für Java und JavaScript. Wenn Sie darauf achten, nur die EGL in Ihrer Quellendatei zu verwenden, die mit Java und JavaScript kompatibel sind, generiert EGL beide Versionen der Bibliothek.
- Für die Datei MyHandler.egl beginnt EGL mit der Quellendatei und folgt der Verzeichnisstruktur aufwärts, bis die Projektebene erreicht ist. Auf dieser Ebene findet EGL die Standardbuilddeskriptoren des Systems für JavaScript und
generiert eine Datei mit der Erweiterung .js. Die Datei mit der Erweiterung .js ist während der Implementierung in eine HTML-Datei eingebettet.
Beispiel 2: Generierungsfehler
Dieses Beispiel zeigt, was passiert, wenn Sie eine Standardbuilddeskriptoroption auf einer zu hohen Ebene angeben. Angenommen, Sie können in derselben Situation wie im vorigen Beispiel den Standardbuilddeskriptor für Java auf Projektebene anordnen.
<- JavaScript default build descriptor (system)
UIProject <- Java default build descriptor (user)
EGLSource
handlers
MyHandler.egl
libraries
MyLibrary.egl
UIProject.eglbld
...
EGL löst die Standardbuilddeskriptoren wie folge auf:
- Für MyLibrary.egl beginnt EGL mit der Quellendatei und folgt der Verzeichnisstruktur aufwärts, bis die Projektebene erreicht ist, wo sich die Standardbuilddeskriptoren für Java (angepasst) und JavaScript (System) befinden. EGL generiert beide Versionen der Bibliothek wie im vorigen Beispiel.
- Für MyHandler.egl beginnt EGL mit der Quellendatei und folgt der Verzeichnisstruktur aufwärts, bis die Projektebene erreicht ist, wo sich dieselben Standardbuilddeskriptoren für Java und JavaScript befinden. Da kein Rich-UI-Handler als Java generiert werden kann, erfolgt der Abbruch mit einem Fehler.
Beispiel 3: Benutzerschnittstelle und Service in demselben Projekt generieren
Erstellen Sie einen angepassten Builddeskriptor auf Paketebene, um die Java-Generierung zu steuern.
Dieses Projekt enthält einen dedizierten Service und keine Bibliothek:
UIProject <- JavaScript default build descriptor (system)
EGLSource
handlers
MyHandler.egl
services <- Java default build descriptors (user)
MyService.egl
UIProject.eglbld
...
EGL löst die Standardbuilddeskriptoren wie folgt auf:
- Für den Service MyService.egl beginnt EGL mit der Quellendatei und folgt der Verzeichnisstruktur aufwärts, bis die Paketebene erreicht ist. Auf dieser Ebene findet EGL angepasste Standardbuilddeskriptoren für Java und
generiert den Java-Service.
- Für die Datei MyHandler.egl beginnt EGL mit der Quellendatei und folgt der Verzeichnisstruktur aufwärts, bis die Projektebene erreicht ist. Auf dieser Ebene findet EGL die Standardbuilddeskriptoren des Systems für JavaScript und
generiert eine Datei mit der Erweiterung .js.
Beispiel 4: Benutzerschnittstelle und Service in separaten Projekten generieren
Sie können die Anpassung der Standardbuilddeskriptoren vollkommen vermeiden, indem Sie Ihren Rich-UI-Handler und Ihren Service in separate Projekte stellen. Im folgenden Diagramm ist das UIProject wieder eine Rich-UI-Projekt und das ServiceProject ist ein allgemeines Projekt:
ServiceProject <- Java default build descriptor (system)
EGLSource
Services
MyService.egl
ServiceProject.eglbld
...
UIProject <- JavaScript default build descriptor (system)
EGLSource
handlers
MyHandler.egl
UIProject.eglbld
...
EGL löst die Standardbuilddeskriptoren wie folgt auf:
- Für die Datei MyService.egl beginnt EGL mit der Quellendatei und folgt der Verzeichnisstruktur aufwärts, bis die Projektebene erreicht ist. Auf dieser Ebene findet EGL Standardbuilddeskriptoren des Systems für Java und
generiert den Java-Service.
- Für die Datei MyHandler.egl beginnt EGL mit der Quellendatei und folgt der Verzeichnisstruktur aufwärts, bis die Projektebene erreicht ist. Auf dieser Ebene findet EGL die Standardbuilddeskriptoren des Systems für JavaScript und
generiert eine Datei mit der Erweiterung .js.
Masterbuilddeskriptor und Builddeskriptorketten
Ihr Systemadministrator fordert Sie möglicherweise auf, einen Masterbuilddeskriptor zu verwenden. Diese Art von Builddeskriptor enthält Informationen, die nicht überschrieben werden können und die für jede Generierung gelten, die in Ihrer EGL-Installation erfolgt. Der Systemadministrator ermittelt diesen Abschnitt zusammen mit der EGL-Builddatei, die den Abschnitt enthält, nach dem Namen. Informationen dazu, wie der Masterbuilddeskriptor definiert wird, finden Sie unter Masterbuilddeskriptor einrichten.
Sie können eine Kette aus Builddeskriptoren von einem generierungsspezifischen Builddeskriptor erstellen, so dass das erste Element in der Kette vor dem zweiten verarbeitet wird und das zweite vor dem dritten usw. Wenn Sie einen bestimmten Builddeskriptor definieren, beginnen Sie eine Kette (oder setzen eine Kette fort), indem Sie einen Wert zur Builddeskriptoroption nextBuildDescriptor zuordnen. Ihr Systemadministrator kann dieselbe Technik verwenden, um eine Kette vom Masterbuilddeskriptor zu erstellen. Die Auswirkung der Verkettung wird später beschrieben.
Jeder Buildabschnitt, der von einem Builddeskriptor referenziert wird, muss für den referenzierenden Builddeskriptor sichtbar sein. Der Buildabschnitt kann zum Beispiel ein Verbindungsoptionsabschnitt oder ein Ressourcenzuordnungsabschnitt oder der nächste Builddeskriptor sein.
Rangfolge der Optionen
Für eine bestimmte Builddeskriptoroption bleibt der Wert, der ursprünglich zur Generierungszeit verarbeitet wurde, weiterhin wirksam. Die allgemeine Ausführungspriorität ist folgende:
- Masterbuilddeskriptor
- Bestimmte Builddeskriptoroptionen, die Überschreibungswerte enthalten, die zur Generierungszeit angegeben wurden, wenn Sie die Menüoption Mit Assistenten generieren... verwenden. Diese Optionen können Werte nicht überschreiben, die im Masterbuilddeskriptor festgelegt wurden.
- Generierungsspezifischer Builddeskriptor, gefolgt von der Kette, die von diesem ausgeht.
- Die Kette, die vom Masterbuilddeskriptor ausgeht
Der Vorteil dieses Schemas liegt im Komfort:
- Der Systemadministrator kann unveränderliche Wert angeben, indem er einen Masterbuilddeskriptor definiert.
- Sie können generierungsspezifische Builddeskriptoren verwenden, um Werte zuzuordnen, die für eine bestimmte Generierung spezifisch sind.
- Ein Projektmanager kann eine Reihe von Standards festlegen, indem er einen oder mehrere Builddeskriptoren anpasst. In den meisten Fällen, zeigen generierungsspezifische Builddeskriptoren auf den ersten Builddeskriptor in einer Kette, die vom Projektmanager entwickelt wurde. Standardoptionen können sinnvoll sein, wenn Ihr Unternehmen eine Reihe von Programmen entwickelt, die auf ähnliche Weise generiert oder vorbereitet werden müssen.
- Der Systemadministrator kann eine Reihe von allgemeinen Standards definieren, indem er eine Kette aufbaut, die vom Masterbuilddeskriptor ausgeht.
Es ist ungewöhnlich, diese Funktion zu verwenden.
- Wenn Sie bestimmte Builddeskriptoroptionen wie zum Beispiel die Zielbenutzer-ID oder das Kennwort überschreiben müssen, können Sie dies ohne Konfiguration eines anderen Builddeskriptorabschnitts tun.
Wenn ein bestimmter Builddeskriptor mehr als einmal verwendet wird, ist nur der erste Zugriff auf diesen Builddeskriptor wirksam. Ferner ist auch nur die erste Spezifikation einer bestimmten Option wirksam.
Beispiel 5: Builddeskriptorketten
Angenommen, der Masterbuilddeskriptor enthält die folgenden hypothetischen Option-Wert-Paare:
OptionX 02
OptionY 05
In diesem Beispiel enthält der generierungsspezifische Builddeskriptor mit dem Namen 'myGen' die folgenden Option-Wert-Paare:
OptionA 20
OptionB 30
OptionC 40
OptionX 50
Wie in 'myGen' angegeben, lautet der nächste Builddeskriptor 'myNext01' und enthält die folgenden Paare:
OptionA 120
OptionD 150
Wie in 'myNext01' angegeben, lautet der nächste Builddeskriptor 'myNext02' und enthält die folgenden Paare:
OptionB 220
OptionD 260
OptionE 270
Wie im Masterbuilddeskriptor angegeben, lautet der nächste Builddeskriptor 'myNext99' und enthält die folgenden Paare:
OptionW myUserID
OptionZ 99
EGL akzeptiert Optionswerte in der folgenden Reihenfolge:
- Werte für Optionen im Masterbuilddeskriptor:
OptionX 02
OptionY 05
Diese Optionen überschreiben alle anderen Optionen.
- Werte im generierungsspezifischen Builddeskriptor 'myGen':
OptionA 20
OptionB 30
OptionC 40
Der Wert für 'OptionX' in 'myGen'
wurde ignoriert.
- Werte für andere Optionen in 'myNext01' und 'myNext02':
OptionD 150
OptionE 270
Der Wert für 'OptionA' in 'myNext01' wurde ignoriert. Ebenso wurden die Werte für 'OptionB' und 'OptionD' in 'myNext02' ignoriert.
- Werte für andere Optionen in myNext99:
OptionW myUserID
OptionZ 99
- Zusätzlich können Sie bei Verwendung des Assistenten für die Generierung auswählen, dass bestimmte Builddeskriptoroptionen wie Zielbenutzer-ID und Kennwort für Systeme überschrieben werden, in denen die Generierungsausgabe für die Implementierung vorbereitet wird. Wenn zum Beispiel 'OptionW' in 'myNext99'
die Builddeskriptoroption destUserID ist und Sie den Assistenten für die Generierung verwenden, können Sie den Wert für
'OptionW' zur Generierungszeit festlegen.