Session D-ACOD
ACODEY - Flexible Klassen-
Bausteine
Christof Lange
ProLib Software GmbH
Acodey, ein neues Konzept für bekannte Probleme
Kennen Sie das? Eigentlich ist das Framework ja ganz gut, aber warum müssen Sie den unbedingt alle Klassen in Ihre Applikation einbinden, auch wenn Sie nur einen Teil davon
benutzen? Und warum muß die eine Klasse ausgerechnet so heißen, wie eine von Ihnen erstellte Klasse? Und was ist mit der Oberfläche? Warum nur können nicht Sie entscheiden, wie die Applikation auszusehen hat, warum wurde diese
Entscheidung für Sie getroffen? Und warum müssen die Klassen auch so groß sein, warum muß das Formular die gesamte Eingabesteuerung, die Benutzerverwaltung, die Überprüfung der Daten, etc. vornehmen?
Mit Acodey versuchen wir diese Probleme zu lösen. Alle Funktionalitäten eines Frameworks wuzrden für Acodey in einzelne kleine Komponenten ausgelagert. Bei der Ermittlung, welche
Funktionalitäten eine Komponente abdecken soll, haben wir verschiedene Kriterien angewandt. Anstatt Komponenten möglichst groß zu machen, damit wir sie einfach und teuer verkaufen können, haben wir uns entschieden, diese möglichst
klein und schlank zu machen. Jede Komponente ist unabhängig von anderen Komponenten. Und jede Komponente deckt nur eine bestimmte Funktionalität ab, kann aber mit anderen Komponenten kombiniert werden, um einen größere Aufgabe zu
erledigen. Lassen Sie mich das an einem Beispiel illustrieren.
Nehmen wir einmal ein einfaches Stammdatenformular. In Acodey steckt nicht die gesamte Logik im Formular selbst. Um einzelne Funktionalitäten zu ersetzen oder die Optik zu ändern,
müssen Sie nicht das komplette Formular neu erstellen. Vielmehr ist das Formular in Acodey selbst dumm, so dumm, daß Sie das VFP-Basisformular verwenden können. Für die Eingabeelemente können Sie beliebige Klassen verwenden. Für die
Ansteuerung der Daten verwenden Sie ein DataBehavior. Dies kann ein DataBehavior sein, das Tabellen, Views, SELECT-Befehle, oder was auch immer verwendet. Die DataBehavior können in
einer Datenumgebung zusammengefaßt werden, die von einem BusinessObject verwendet wird. Das BusinessObject wird vom IONavControl als Datenquelle verwendet. Das IONavControl verwaltet den aktuellen Status eines Formulares. Für die
Steuerung der Oberfläche, wie das Deaktivieren von Controls, verwendet es das IOControl. Um mit einem Toolbar zu kommunizieren, kann das IONavControl
Ereignisse auslösen, die von einem IONavReceiver empfangen werden und über das Messaging an einen IONavSender
weitergeleitet werden. Beim Speichern versucht ein UpdateConflictHandler eventuelle Konflikte zu lösen und informiert den Anwender.
Auch wenn dies nun ziemlich verwoben klingt, lassen Sie sich davon nicht täuschen. Das obige Szenario ist nur eines von vielen, wie Sie Acodey-Komponenten miteinander verknüpfen können.
Sie wollen kein BusinessObject verwenden? Gut, dann lassen Sie es sein und lassen Sie das IONavControl direkt ein DataBehavior steuern. Toolbar über Messaging, das ist nichts für Sie? Dann rufen Sie aus Formularmethoden doch einfach
die Methoden des IONavControl direkt auf.
Wenn in Acodey Komponenten aufeinander zugreifen, tun Sie das immer nur über eine Objektreferenz bzw. die Angabe einer Klasse und die öffentliche Schnittstelle. Sie können daher
jeden einzelnen Bestandteil ersetzen, bzw. sogar in einer anderen Sprache schreiben. So würde sie rein theoretisch nichts daran hindern, das IOControl in Visual Basic zu schreiben, das IONavControl und die Datenumgebung in Visual FoxPro. Das Ergebnis ist, daß Sie ein Visual Basic Formular entwickeln können, das direkt an FoxPro-Tabellen gebunden ist und einige Visual Basic
Komponenten zusammen mit einigen Acodey Komponenten verwendet. Testweise haben wir das bereits getan, um die Flexibilität von Acodey zu testen.
Aber nicht nur bezogen auf die Funktionalität und Kombinierbarkeit ist Acodey flexibel. Anstatt fertig vordefinierte Klassen zu verwenden, bietet Acodey mit dem Integrationsassistenten ein Werkzeug an, mit dem Sie die Klassenbibliotheken selbst erstellen können. Sie entscheiden, welche Klassen Sie verwenden möchten, wobei Abhängigkeiten automatisch gelöst werden. Sie entscheiden, ob
Sie eine Zwischenschicht haben möchten, um eigene Anpassungen auf allen Ebenen machen zu können. Sie entscheiden sogar, wie die Klassen heißen sollen und was für VCX-Dateien Sie verwenden möchten. Darüber hinaus entscheiden Sie,
welche Verzeichnisstruktur verwendet werden soll und sogar, wie die Prozeduren heißen. Was Sie nicht ändern können, sind die Namen von Methoden und Eigenschaften, ansonsten haben Sie fast völlig freie Hand.
Gehören Sie auch zu den Entwicklern, die ein Framework erst verstehen möchten, bevor Sie es anwenden? Dann ist Acodey ebenfalls das richtige Tool für Sie, denn etwa die Hälfte
des Quellcodes besteht aus ausführlichen Kommentaren, die erläutern, was im folgenden geschieht, warum es ausgerechnet so geschieht, und welche Bugs von Visual FoxPro hierbei zu berücksichtigen waren.
Haben Sie Sorgen, daß Acodey zu langsam wird, wenn es so flexibel ist? Die brauchen Sie nicht zu haben, denn viele Optionen von Acodey lassen sich über Include-Dateien steuern. Sie
wählen, ob Ihre Applikation eher schnell oder eher stabil laufen soll. Sie wählen, ob die Testversion sie bei der Suche nach Programmfehlern unterstützen soll, oder ob Sie lieber Fehler in Kauf nehmen und dafür die Version schnell
fertig haben. Sie wählen, ob Acodey Ihnen bei der Beseitigung von hängenden Referenzen unterstützen soll, oder ob Sie das selber übernehmen wollen. Sie wählen, ob Sie eine feste Sprache, oder dynamische Sprachumschaltung zur Laufzeit wünschen.
Sie wählen...., ja, eigentlich wählen Sie eine ganze Menge:
Da Acodey aus Komponenten aufgebaut ist und nicht aus einem fest verdrahteten Framework, können wir Updates zu einzelnen Komponenten oder gar neue Komponenten relativ schnell
anbieten. Derzeit ist eine Webanwendung in Entwicklung, mit der Sie einzelne Komponenten kaufen können, von der kleinsten bis zur größten Komponente. Zum Zeitpunkt der Erstellung dieses Dokumentes enthält Acodey unter anderem folgende
Komponenten:
Komponente
|
Beschreibung
|
AcodeyForm
|
Basisklasse für Formulare mit Datenumgebung und SET-Einstellungen
|
CommaList
|
Splittet Listen in einem String in einzelne Elemente auf
|
Command
|
Führt VFP-Befehle aus (auch im Errorhandler).
|
CursorBehavior
|
DataBehavior für mit CREATE CURSOR erstellt Cursor.
|
C_IONavButtons
|
Composite: Navigationsleiste als Container
|
C_IONavFormButtons
|
Composite: Navigationsleiste zur Verwendung auf Formularen
|
C_IONavToolbar
|
Composite: Navigationstoolbar
|
C_SimpleDataForm
|
Composite: Einfaches Dateneingabeformular
|
DataBehavior
|
Abstrakte Basisklasse zur Steuerung von diversen Datenquellen.
|
DataEnvironmentX
|
Datenumgebung für DataBehavior-Objekte
|
DatasessionPool
|
Pool zur Verwaltung von Datasessions
|
IOControl
|
Verwaltet Ansichten für ein Formular.
|
IONavControl
|
Formular- und Datensteuerung
|
IONavRemoteReceiver
|
Fernsteuerung für das IONavControl (Empfänger)
|
IONavRemoteSender
|
Fernsteuerung für das IONavControl in Toolbars, etc.
|
Iterator
|
Objekte in Containern enumerieren
|
LocalViewBehavior
|
DataBehavior für lokale Views (Ansichten)
|
Messaging
|
Sendet und empfängt applikationsweit Nachrichten
|
MultiContainerController
|
Verwaltet mehrere Container für Assistentenformulare
|
NamedPipe
|
Dynamische 1:1 Verbindungen aufbauen.
|
SimplePoolMgr
|
Verwaltet einen "Pool" des gleiches Objekttyps
|
SqlDataBehavior
|
Databehavior für SELECT-basierte Cursor
|
TableBehavior
|
Databehavior für VFP Tabellen (.DBF-Dateien)
|
TemporaryDatabase
|
Verwaltet eine temporäre Datenbank und temporäre Dateien.
|
UpdateConflictHandler
|
Löst und verwaltet Aktualisierungskonflikte.
|
|