Mittels TChromium Dialoge Dialoge von VCL auf HTML umstellen

[rweinzierl]

Hallo

Wir haben eine großere über Jahrzehnte gewachsene Delphi Anwendung. (Ein nicht geringer Teil ist in C++ geschrieben)

Wir überlegen wie wir die Anwendung modernisieren können so dass unsere Kunden diese auch Online nutzen könnten.
(z.B von Tablet aus.) Auch ein optisches Facelifting würde der Anwendung gut tun.

Aufgrund des Umfangs / Bedeutung fällt ein einfach fürs Web alles parallel neu zu entwickeln aus (Kosten !).

Jetzt kam die Idee auf HTML5 für die Dialogerstellung zu nutzen und die TChromium komponente für die Anzeige einzubinden.

Also Dialog für Dialog von VCL auf HTML umzustellen und erst mal als normale Desktopanwendung weiter zu verwenden / ausliefern.

Sobald dann die entscheidenden Dialoge umgestellt sind, die Anwendung auch auf einem Webserver veröffentlichen und die Gelegenheitsanwender darauf verweisen.

Wenn die Webanwendung die gleiche Performance / Stabiliät /Versionsumfang der aktuellen Desktoplösung bietet dann auch die Key Anwender umstellen.

(TChromium und nicht TWebbrowser (IE) da besser kontrollierbar, definierte Version ...)

Bin gespannt auf eure Meinungen.

Fürs lesen schon mal Dankeschön

mfg

Reinhold

[mjustin]

Zitat von rweinzierl:

Jetzt kam die Idee auf HTML5 für die Dialogerstellung zu nutzen und die TChromium komponente für die Anzeige einzubinden.

Also Dialog für Dialog von VCL auf HTML umzustellen und erst mal als normale Desktopanwendung weiter zu verwenden / ausliefern.

Wie soll der Transport der im Dialog eingegebenen Daten zurück an das Delphi Programm denn realisiert werden?

Ich sehe als Möglichkeiten:

* klassische HTML Formulare, die dann aber eine Adresse auf einem HTTP Server benötigen, zu der die eingegebenen Daten gesendet werden. Der Webserver kann dazu im Prinzip direkt in der EXE Datei eingebettet werden.

* HTML mit JavaScript - auf allen Input Feldern liegen Eventhandler, um auf jeden Tastendruck oder Mausbewegungen reagieren zu können, und eine Ajax Schnittstelle zum Server (weiter siehe oben). Damit sind auch Aktualisierungen des Formulars ohne komplettes Neuladen möglich.

* TChromium kann sicher auf das HTML Dokument und seine Forumlar-Elemente auch lesend und schreibend zugreifen - und vermutlich auch Ereignisse wie das Drücken der Submit Taste abfangen, um die weitere Verarbeitung zu starten. Vorteil: es ist kein integrierter HTTP Server notwendig. Nachteile?...

[Bernhard Geyer]

Zitat von mjustin:

* TChromium kann sicher auf das HTML Dokument und seine Forumlar-Elemente auch lesend und schreibend zugreifen - und vermutlich auch Ereignisse wie das Drücken der Submit Taste abfangen, um die weitere Verarbeitung zu starten. Vorteil: es ist kein integrierter HTTP Server notwendig. Nachteile?...

Das man diese Lösung nicht einfach irgendwann auf den WebServer legen kann sondern nochmal grundlegend überarbeiten muss.

[rweinzierl]

Hallo

Zitat von Bernhard Geyer:

Zitat von mjustin:

* TChromium kann sicher auf das HTML Dokument und seine Forumlar-Elemente auch lesend und schreibend zugreifen - und vermutlich auch Ereignisse wie das Drücken der Submit Taste abfangen, um die weitere Verarbeitung zu starten. Vorteil: es ist kein integrierter HTTP Server notwendig. Nachteile?...

Das man diese Lösung nicht einfach irgendwann auf den WebServer legen kann sondern nochmal grundlegend überarbeiten muss.

Klar die Kommunikation zwischen eingebetteter Variante und später richtigem Web Server wird sich unterscheiden müssen. Wobei ich natürlich versuchen werde einen allgemeinen Ansatz festzulegen der dann auf beiden Welten funktioniert.


Reinhold

[mkinzler]

Ansätze wie WebFMX wären vielleicht auch noch eine Alternative.

[rweinzierl]

Zitat von mkinzler:

Ansätze wie WebFMX wären vielleicht auch noch eine Alternative.

Cool was es nicht alles gibt, danke für den Tipp schaue ich auf alle Fälle noch genauer an.

Danke

Reinhold

[Bernhard Geyer]

Zitat von mkinzler:

Ansätze wie WebFMX wären vielleicht auch noch eine Alternative.

Hier würde mich die Serverbelastung interessieren? Schaut mit sehr nach "RemoteDesktop"-Lösungansatz aus.
Die Preis sind ja auch "interessant" (http://www.cybelesoft.com/buy/)
Bei 250 Kunden wäre man schon mindestens 1 Mio. € los

[mkinzler]

Wenn du für jeden Kunden einen eigenen "Server" nimmst. Ein Server kann aber mehrere Anwendungen hosten. Implementiert wird dies durch einen alternativen Canvas für FMX ( wie Windows, OSX, iOS, ...) ähnlich der remote Funktionalität von GTK.

[Bernhard Geyer]

Zitat von mkinzler:

Wenn du für jeden Kunden einen eigenen "Server" nimmst.

U.u. ist das ja für die Anwendung zwingend Notwendig. Nicht jeder Kunde vertraut seine Daten der Cloud an bzw. hat eh eine Hausinterne EDV die das halt dann auch mit hostet.

[rweinzierl]

Hallo

Habe ich die Preisliste von WebFmx richtig verstanden 1 Server egal wieviel Ram und Prozessoren 2500 $ + Entwicklerlizence 325 $ ==>2200 Euro und ich kann darauf mein Programm so oft laufen lassen wie ich will.

Ein Server kann heute ja 128 GB Ram haben da sollte mein Programm ein paarmal parallel funktionieren.

Im Vergleich zu einer Neuentwicklung wäre das günstig. (Egal wo ich es Hoste)

Wenn es wirklich stabil funktioniert ein guter Tipp. (Die Demo ist mir mit einem Fehlermeldung in der Serverseitigen exe abgestürzt)

mfg

Reinhold