TopLogic-Konzepte
Die TopLogic Application Engine besteht aus einer Vielzahl aufeinander aufbauender Konzepte. Verlässt man die reine in-app Konfiguration von Anwendungen und möchte Erweiterungen für die Engine implementieren, muss man einen Überblick über das Zusammenspiel haben. Dieses Kapitel liefert einen Überblick und kann als Einstiegspunkt in den Quellcode und die damit verknüpfte API-Dokumentation verwendet werden.
Modell
Im Zentrum einer Anwendung steht das Fachmodell, das die Anwendungsdaten beschreibt. Über Annotationen an die Modell-Elemente werden eine Vielzahl von UI-Funktionen gesteuert. Das Modell kann in der Anwendung selbst eingesehen und erweitert werden, siehe Daten-Modellierung.
Die Schnittstelle TLModel
bietet Zugriff auf alle Module (TLModule
) einer Anwendung und deren Typen. Normale Fachobjekte werden über eine Klasse TLClass
beschrieben. Wie aus UML bekannt haben Klassen Attribute, die in einfache Eigenschaften (TLProperty
) und Referenzen (TLReference
) auf andere Objekte unterteilt sind. Alle Attribute können verpflichtend oder optional sein. Bei einem verpflichtenden Attribut muss eine Eingabe erfolgen, damit ein Objekt angelegt oder die Bearbeitung in einem Editor abgeschlossen werden kann. Referenzen können als Komposition ausgezeichnet sein. Dann beschreiben sie eine Teil-Ganzes-Beziehung und kontrollieren zusätzlich die Lebenszeit des referenzierten Objektes.
Die Modell-Klassen existieren in zwei Varianten. Eine transiente Variante (z.B. TLClassImpl
) und eine persistente Variante für die Repräsentation von Modell-Elementen, die als Objekte in der Datenbank abgelegt sind (z.B: PersistentClass
) .
Modell-XML
Das Initialmodell der Anwendung wird über XML-Dateien geladen. In der Regel wird jedes Modul in einer separaten Model-XML-Datei gespeichert. Im Entwicklungsprojekt befinden sich die Modell-Dateien im Ordner src/main/webapp/WEB-INF/model
. Nach einem in-app Entwicklungsschritt können neue Module oder änderungen an bestehenden Module wieder in die Entwicklungsumgebung exportiert werden, um in ein neues Deployment der produktiven Anwendung einzufließen.
Das Schema der Model-XML-Dateien ist über typisierte Konfiguration beschrieben. Das Konfigurations-Interface für ein Modul ist beispielsweise ModuleConfig
, das für eine Klasse ClassConfig
und das für eine Referenz ReferenceConfig
. Beim Anwendungsstart werden Änderungen in den Model-XML-Dateien mit dem in der Anwendung geladenen Modell abgeglichen und bei Bedarf in Änderungen an den Modell-Elementen übersetzt.
Typisierte Konfiguration
Die typisierte Konfiguration beschreibt ein Schema für XML-Dateien über Java-Interfaces. Hierbei entspricht grob ein Konfigurationsinterface einem XML-Tag und seine Properties (repräsentiert durch die Getter-Methoden des Interfaces) den Attributen und Subtags. Alle Konfigurationsinterfaces sind Ableitungen von ConfigurationItem
. XML-Dateinen können zu Instanzen der Konfigurationsinterfaces über ConfigurationReader
geparst und über ConfigurationWriter
wieder in XML serialisiert werden.
Spezielle Konfigurationsinterfaces sind Ableitungen von PolymorphicConfiguration
. Diese stellen Konfigurationsoptionen für Implementierungsklassen bereit. Die typisierte Konfiguration hat Mechanismen eingebaut, mit denen konfigurierbare Anwendungsklassen instanziiert und mit Konfigurationen versehen werden können.
Fast alle Konfigurationsdateien in TopLogic haben ein Schema, das über typisierte Konfiguration beschrieben ist. Das Plug-In-Konpept von TopLogic, mit dem Implementierungen ausgetauscht und hinzugefügt werden können, basiert ebenfalls auf der typisierten Konfiguration. Das Kapitel Typisierte Konfiguration beschreibt die Mechanismen der typisierten Konfiguration im Detail.
Anwendungslayout
Die Sichten einer Anwendung sind aus Bausteinen zusammengesetzt. Diese Bausteine heißen Komponenten. Technisch ist eine Komponente durch eine Implementierung von LayoutComponent
repräsentiert. Die Aufgabe einer Komponente ist es, ein über das Anwendungsmodell beschriebenes Fachobjekt in ein technisches GUI-Modell zu übersetzen. Komponenten können miteinander über Komponentenkanäle interagieren. Die beiden wichtigsten Komponentenkanäle sind model
und selection
. Typischerweise zeigt eine abhängige Komponente (z.B. ein Formular) die Selektion ihrer übergeordneten Komponente (z.B. einer Tabelle) als Modell an. Dies wird realisiert, indem der Komponentenkanal model
der abhängigen Komponente mit dem Kanal selection
der übergeordneten Komponente verknüpft wird.
Es gibt eine Vielzahl von Komponenten für die unterschiedlichen top-level Bausteine einer Anwendung, z.B. Baum (TreeComponent
), Tabelle (TableComponent
), Formular (FormComponent
), Grid (GridComponent
), Tabbar (TabComponent
). Ein Formular übersetzt beispielsweise das anzuzeigende Fachobjekt in ein technisches Modell den FormContext
, welcher für jedes Attribut des zu editierenden Objektes ein Eingabefeld (FormField
) enthält. Die letztendliche Darstellung der UI-Modelle wird über in der UI-Schicht über Control
s realisiert.
Layout-XML
Formularmodelle FormContext - FormField - FormMember
UI-Schicht (Produzieren von HTML aus Modellen): Controls - SelectControl - SelectionControl - ....
Persistenzschicht (OR-Mapping Object -> DB, Versionierung): KnowledegeBase - KnowledgeObject - KnowledgeItem
Technische Kommunikation mit dem Browser: LayoutServlet - AjaxServlet
Services - ManagedClass
TL-Script