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. 

 

vorheriger Vortrag E-MERE

zur Übersicht der Gruppe FWK

nächster Vortrag E-TIER

 

dFPUG c/o ISYS GmbH

Frankfurter Str. 21 b

 

D-61476 Kronberg

per Fax an:

+49-6173-950903

oder per e-Mail an:

konferenz@dfpug.de

© Texte, Grafiken und Inhalt: ISYS GmbH