UI-Zukunft (2), Demo

29/07/2011 - 17:46 von W. Wolf | Report spam
Hallo,

ich bin noch immer der Meinung dass HTML&JS eine gute Alternative
für zukünftiges UI sein kann. Um mir das Warten auf Olafs WebKit etwas
zu verkürzen, habe ich ein wenig "gebastelt". Das Ergebnis, nichts
weiter als eine Studie basierend auf nwind.mdb / nwind.db (Model),
diverse VB-Klassen und Olafs RC3 (Controller) und Ext4-JavaScript
für das UI findet ihr unter http://www.ww-a.de/download/ExtBrowser.zip
(2 MB, Bin, Quellen und Daten).

In der Exe wird hier das IE-Browser-Control verwendet, aus der
Anwendung heraus kann aber auch der eigene Standard-Browser
aufgerufen werden. Die UI kommuniziert ausschließlich über
HTTP/TCP mit der Bussines-Schicht, so dass die Anwendung auch
als Client/Server mit beliebigen Client-OS und JS-fàhigen Browsern
verwendet werden kann. Kurios dabei ist, dass sich hier die Anwendung
im Browser schneller anfühlt als in der Exe. Das wohl hat damit zu tun, dass
auf meinem Rechner der Firefox5 JS schneller ausführt als mein alter IE6.

Ich habe versucht bereits so was wie eine Architektur in den Untergrund
der Anwendung zu bringen, so dass alle Komponenten leicht austauschbar
sind. Gleiches gilt für die UI-Seite: der Code ist stark modularisiert, so
dass
eine Wiederverwendung einzelner JS-Module möglich wird. Die Festlegung
auf das Ext-Framework in der UI ist nur meine eigene Pràferenz. Das
Framework ist beliebig austauschbar.

Die VB-Exe ist gleichzeitig Web- und Applikationsserver. Aber auch das
kann wahrscheinlich geàndert werden. Wenn die Bussines- und DataLayer-
Klassen in DLLs ausgelagert werden, könnten diese auch im ISS verwendet
werden (auch ohne .Net) und zumindest so lange, wie der IIS noch COM-
DLLs unterstützt.

Noch ist in dieser Studie vieles nicht vollstàndig und ausreichend
durchdacht
ist wohl auch das Wenigste. Aber irgendwo muß man ja anfangen ;-)
Wer Lust hat, kann sich das ja mal ansehen. Würde mich über Kommentare
freuen. Leider habe ich den Quellcode kaum dokumentiert. Das was kommentiert
ist stammt von Olaf oder Ulrich ;-). Ich kenne mich einigermaßen im Code aus
;-),
ich darf auch persönlich unter w.wolf(at)ww-a.de gefragt werden. Da hier
aber
eh nur Profis mitlesen, wird das kaum erforderlich sein.

@Olaf: die einzige Form im Projekt besteht aus nur einer Zeile (wichtigen)
Code: WebBrowser1.Navigate STARTURL & "?RunLocal=true"
Ein Ersetzen des IE-Browsers mit deinem WebKit dürfte nicht aufwendig
sein. Hàttest du Lust das mal zu testen?

Schöne Grüße und ein schönes Wochenende
W. Wolf
 

Lesen sie die antworten

#1 W. Wolf
30/07/2011 - 16:28 | Warnen spam
Hallo,

möchte noch ein paar Gedanken nachschieben:

Der VB-Programmierer der sich die JS-Dateien angesehen hat
und für den JS eine Fremdsprache ist, der wird sich eventuell
fragen was das noch mit VB zu tun hat und ob selber nun eine
weitere Programmiersprache dazulernen muß.

Die klare Antwort darauf lautet: Jein!
Im Ext-Framework wird sehr objektorientiert gearbeitet. An vielen
Stellen im JS-Code werdet Ihr so was wie:
"Ext.define('Klassenname'), { ... };
antreffen. Hier wird eine Klasse inkl. Eigenschaften und Methoden,
teils auch Ereignisse inkl. Ereignisprozeduren definiert. Das muß nicht
zwingend eingetippt werden. Denkbar wàren VB-Funktionen welche
diese Klassen zur Laufzeit oder auch mittels Assistent zur Entwurfszeit
erstellen. Nehmen wir mal die Ext-Klasse Customer aus meinem Beispiel.
Diese sieht in JS wie folgt aus:

Ext.define('Customer', {
extend: 'Ext.data.Model',
fields: ['CustomerID',
'CompanyName',
'ContactName',
'ContactTitle',
'Address',
'City',
'Region',
'PostalCode',
'Country',
'Phone',
'Fax'],
proxy: {
type: 'ajax',
url: 'controllers.customers'
}
}
füttert man damit die Klasse cAppJSON aus der VB-Anwendung,
so entsteht daraus folgendes VB-Object:

object: cCollection
extend: vbString
fields: vbCollection
CustomerID: vbString
CompanyName: vbString
ContactName: vbString
ContactTitle: vbString
Address: vbString
City: vbString
Region: vbString
PostalCode: vbString
Country: vbString
Phone: vbString
Fax: vbString
proxy: cCollection
type: vbString
url: vbString

also eine Hierarchie aus cCollections, vbCollections und Wertetypen.
Diese Objekte können auch mittels VB-Code in den Business-Klassen
erstellt werden. Die Funktion toString erzeugt daraus wieder den JS-Code.

Damit bieten sich drei Vorgehensweisen bei der Implementation an:
1. Die JS-Klassen werden in den Business-Klassen zur Laufzeit aus normalen
VB-Objekten erzeugt, indem das Root-Objekt an die Klasse cAppJSON
übergeben wird.
2. Die Klassen werden vom UI-Programmierer in JS programmiert und
als normale js-Files abgelegt (das habe ich in meinem Beispiel gemacht).
3. Ein VB-Assistent ermöglicht das "visuelle" Zusammenstöpseln der Objekte
und erzeugt daraus die fertigen JS-Klassen. Diese können nachtràglich direkt
im JS-Code oder im Assistent (bidirektional) bearbeitet oder erweitert
werden.

Das was mir an diesem Konzept sehr gefàllt ist, dass die JS-Klassen
auch vom Endanwender erzeugt werden können. Damit kann sich der
Endanwender im Rahmen dessen was die Business-Klassen zulassen,
eigene FrontEnds zusammenbauen und diese in jedem beliebigen
Browser ausführen. Das Zusammenbauen kann weitestgehend nach dem
Baukastenprinzip erfolgen. Kleine zueinander passende JS-Module werden
wie Lego-Steine in die zentrale HTM-Datei deklarativ eingebunden.

In meinem Beispiel habe ich das nicht ganz so konsequent durchgezogen.
Noch finden sich die Funktionen loadOrders und loadOrderPos in der
zentralen winCustomers.js. Das sollte aber so nicht sein. Diese
Aufruffunktionen
könnten auch als Konstruktoren in den tbl-Klassen implementiert werden
(bestimmte Erkenntnisse bekommt man immer erst nach der Fertigstellung ;-)

Schönen Gruß
W. Wolf

Ähnliche fragen