Datenbank-Definierte Forms, suche geeignetes Scripting Tool

[Medium]

Hallo DP,

mir schwirrt seit geraumer Zeit das Bedürfnis im Kopf, unsere Software grundlegend umzustrukturieren. Es handelt sich dabei um ein loses Rahmenwerk von visuellen Komponenten gemischt mit einer Hand voll Standardcontrols und ein paar Database-Helferlein, woraus wir maßgeschneiderte Programme zur Anlagenvisualisierung und -steuerung in der Industrie stricken. Das aktuelle System funktioniert auch hervorragend, jedoch ist es mir ein Dorn im Auge, bei jeder kleinen Änderung oder Korrektur das Programm auf allen Arbeitsstationen austauschen zu müssen. (Da dies per Fernwartung, teils auch über alte ISDN Leitungen geht, ist das ein merkbarer Zeitfaktor. Zudem unterbrechen so auch kleine Dinge den laufenden Betrieb, oder man muss es dann tun, wenn gerade keine Schicht arbeitet. Bei 24h Betrieben auch schwer.)

Diese Software ist grunstäzlich immer so aufgebaut, dass die jeweilige Anlage auf mehrere einzelne Fenster in sinnvollen Gruppierungen von Maschinen verteilt dargestellt ist. Dort sind Zustände (eingeschaltete Motoren, geöffnete Ventile etc.) grafisch dargestellt, und oftmals sind Bedienungen in Form von Button-Clicks oder auch Werteingaben in Editfelder möglich. Am unteren Bildrand befindet sich eine Knopfleiste, über die die einzelnen Bilder aufgerufen werden können.

Ein Bild besteht bei mir aus je einem eigenen Formular, dass ich bisher "klassisch" im Delphi Formdesigner zusammenstelle und mit den Eventhandlern verknurpsel. (Diese machen meist auch nur 1-2 Aufrufe von Funktionen unserer Utility-Lib.)
Ich würde aber gerne dort hin kommen, dass das eigentliche Programm an sich weitgehend leer ist. Es soll sich zur Laufzeit seine vorhandenen Bilder mitsamt aller darauf befindlichen Komponenten aus einer zentralen Datenbank abholen, alles instanziieren, und dann weiter machen wie bisher. Was die visuellen Dinge angeht ist das so weit auch kein unlösbares Problem: Ich denke dabei daran die *.dfm in ein BLOB zu werfen, pro Bild/Formular ein Datensatz, und dann (hoffentlich) mittels TParser entsprechend zerpflücken zu können.

Interessanter werden die Funktionen, da die dann ja nicht mehr einkompiliert werden können! Also muss ein Script auf den Tisch. Dieses sollte idealerweise ermöglichen, dass ich wie in Delphi auch auf alle Funktionen diverser Units im Programm Zugriff habe, und vor allem auch die Komponenten, die aus der Datenbank dynamisch erzeugt wurden. Ich kann also nicht schon zur Compile-Time ein fertiges Interface zum Script liefern, da dies sich teilweise auch erst zur Runtime ergibt.
Die Scripts würde ich dann ebenfalls gerne in eine Tabelle gießen, so dass ich für Änderungen letztlich nur meine entsprechenden Datensätze ändern muss, und schon sind alle Clients auf der Anlage versorgt.

Frommer Wunsch 1: Neuladen aller Formulare und Funktionen zur Runtime, so dass im laufenden Programm ein Click reicht, um geänderte Dinge sofort parat zu haben. Ohne Programmneustart (damit sind ein paar Bediener leider schon überfordert, trotz eines prominenten "ENDE" Buttons und nur einem Icon auf dem Desktop).

Frommer Wunsch 2: Integration des Script-Editors in Delphi zwecks Code-Vervollständigung - aber das ist vermutlich wirklich eher Wunschdenken.

Bevor ich jetzt alle in Frage kommenden Scripting Engines abklapper, wollte ich hier zunächst fragen, ob ihr bereits welche anhand der Anforderungen empfehlen oder gerne auch ausschließen könnt.


Vielen Dank im Voraus!

[mkinzler]

Schau dir mal http://de.wikipedia.org/wiki/AvERP an. Dort wird das ähnlich gelöst

[HPW]

Für GUI-Scripting kann man sich mal PDScript anschauen.
Basiert auf RemObjects pascal-script.

http://www.be-precision.com/products/pdscript/

[WM_CLOSE]

Warum denn nicht gleich HTML/Javascript auf nem Webserver? Nachteil ist, dass man den clientseitigen Quellcode praktisch offenlegt.

[Medium]

Eine reine Weblösung scheidet hauptsächlich deswegen aus, weil dann unsere gesamte Projektinfrastruktur quasi vom Boden aus neu aufgebaut werden müsste. Es ließe sich praktisch nichts wiederverwenden, das ist schlicht nicht praktikabel. (Nicht, dass ich dem Gedanken nicht auch schon ab und an mal ein paar Stündchen Recherche gegönnt hätte ) Ich spiele vor allem auch mit dem Gedanken, bestehende Lösungen darauf hin umzubauen, wobei sich für den Benutzer am Ende nichts erkennbar ändern darf. Ein Browser passt hier überhaupt nicht ins Bild (vor allem nicht für die Multi-Monitor Lösungen).

pdScript liest sich bis jetzt schon mal sehr ansprechend! Vor allem der Preis lädt gewaltig zum Testen ein Insbesondere, dass die embedded Variante wohl einfach DFMs und Quellcode vom Host entgegen nehmen kann, ohne Umwege über Dateien, klingt ja schon fast ZU perfekt und passend mit meinen Ideen von oben! Den kannte ich noch nicht, riesen Dank. Da werde ich mal mindestens ein langes Wochenende mit spielen gehen.

[Medium]

Zu früh gefreut. pdScript arbeitet wohl wirklich nur mit dem normalen TForm, ich brauche aber eine von TCustomForm abgeleitete eigene Formularklasse. Zudem scheint es zwar mit Komponenten klar zu kommen, aber eben auch nur den Standard-VCL Teilen. Wir nutzen fast ausschließlich TMS Controls, ein paar Dinge der JVCL, und eine ganze Palette an In-House entwickelten Controls. Solche DFMs wird mir pdScript wohl leider nicht futtern. (Wäre es nicht als DLL, sondern als Quelle verfügbar, wäre das vermutlich alles problemlos möglich ) Zudem unterhält unsere Form-Klasse einen Thread mit MySQL Zugriff via UniDAC. Wie sich das mit einer DLL u.U. verträgt ist auch schwer abzuschätzen.

@Neumann: Würde deine Lösung hiermit zurecht kommen? (Hab dich leider erst jetzt gesehen, vorhin war die Rote Box wohl wieder etwas faul.)

[HPW]

Tja ein Script kann eben nur das aufrufen was zur Script-Engine gelinkt ist.
Und das ist nun mal bei pdScript nur die Standard-Delphi runtime lib.

Bliebe denn dann noch die Möglichkeit die eigenliche Pascal-Script engine von RemObjects einer eigenen Anwendung hinzuzufügen?
Die würde dann die TMS und JVCL Kompos enthalten.

[Neumann]

Hallo, so etwas hätte ich. Zur Zeit benutze ich es für unser Kassenprogramm, um variable Oberflächen für unsere Kunden zu bauen. Die Idee, daraus etwas zur Anlagensteuerung zu machen habe ich schon lange (komme eigentlich auch aus dem Bereich).

http://www.delphipraxis.net/168991-f...b-der-ide.html


Bei Interesse bitte eine PN.

[sx2008]

Zitat von Medium:

Ich denke dabei daran die *.dfm in ein BLOB zu werfen, pro Bild/Formular ein Datensatz,

Wie soll dieses "Werfen" denn vor sich gehen?
Also nach meinen Erfahrungen sollte man diese Art von Daten nicht in der Datenbank speichern.
In meinen Projekten habe ich z.B. Templates für Reports (=DFM-Dateien des Report-Builders) in der Datenbank gespeichert.
Das Problem entsteht nun bei den Software-Updates.
Man benötigte ein Updatescript um die Blobs in der Datenbank zu aktualisieren.
Im Script mussten immer alle Templates enthalten sein, um auch ganz alte Installationen auf den aktuellen Stand zu bringen.
Manche Kunden hatten aber auch angepasste Templates (z.B. mit ihren Firmenlogo).
Diese Templates wurden natürlich vom Standardscript überbügelt. ==> grosses Geschrei beim Kunden
Manchmal war auch unbekannt, ob ein best. Kunde speziell angepasste Templates benützt.
(unser Fehler, zu wenig Doku)
Also mussten wir ein Backup der gesamten Datenbank anfordern, weil es zu schwierig war
dem Kunden zu erklären wie er aus einer bestimmte Tabelle einige Blobs rausholen kann.

Lange Rede, kurzer Sinn:
wir speichern die Templates nicht mehr in der Datenbank, sondern in einem
Unterverzeichnis und sind bei Updates wesentlich entspannter.

[Medium]

@Furtbichler: COM, irgendwie bekomme ich da nervöses Zucken. Ich muss mir das Vorhaben aber generell noch ein wenig gründlicher überlegen. Ohne vernünftige Planung will ich da jetzt nicht drauf los, im März gibts dank Urlaub hoffentlich mehr Gelegenheit dafür Insbesondere die Implikationen für Änderungen an bestehenden Systemen muss ich sehr sorgfältig betrachten.

@sx2008: Jaaa, mit "Dateien" in BLOBS gehört gespart, damit bin ich mir auch schon mal über die Zehen gerollt. Da hier der Typ, die Anzahl und die Struktur recht starr ist, schwob mir vor für Änderungen kein kleines Tool zu schreiben. Unsere Kunden werden jedenfalls definitiv nicht darin fummeln, im Gegenteil: Ich spiele stark mit dem Gedanken, die Scripte und DFMs zu verschlüsseln. Mit etwas Vorsicht und technischer Hilfe sollte sich unser Repository dann synchron zum Ist-Bestand bei den Kunden verhalten. Es spräche aber auch nichts wirklich gegen Dateien, zumindest bisher sind die Server unter unserer Administration und wir können tun und lassen was wir wollen. Da das aber nicht immer so sein muss, sollte ich zumindest beide Wege in Betracht ziehen.