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:

Zitat von rweinzierl (Beitrag 1214989)

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:

Zitat von mjustin (Beitrag 1215010)

* 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:

Zitat von Bernhard Geyer (Beitrag 1215011)

Zitat:

Zitat von mjustin (Beitrag 1215010)

* 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:

Zitat von mkinzler (Beitrag 1215018)

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:

Zitat von mkinzler (Beitrag 1215018)

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 :oops:

[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:

Zitat von mkinzler (Beitrag 1215024)

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

[mschaefer]

Die Parallelentwicklung von Desktop und Webapplikation aus
einem Code würde so einen Preis tatsächlich rechtfertigen.

Es wäre allerdings gut wenn Embra. sich mal mit diesem Weg
beschäftigen würde.

Grüße in die Runde

[Neumann]

Versuche gibt es einige. Fängt an mit Intraweb, dann noch ETXPascal, Unigui, Raudus und weitere. Raudus funktioniert in seinen Grenzen einigermaßen, ob damit weitergeht weiss man nicht, bei Unigui scheint die Luft raus zu sein und es passiert nichts mehr.

Intraweb habe ich mal versucht, es schien mir aber sehr instabil zu sein. Vielleicht ist es ja inzwischen brauchbar.

[Bernhard Geyer]

Zitat:

Zitat von mschaefer (Beitrag 1215038)

Die Parallelentwicklung von Desktop und Webapplikation aus
einem Code würde so einen Preis tatsächlich rechtfertigen.

Nicht für alle Anwendungsfälle. Stell dir vor du hast 1000 Kunden welche die Lösung bei sich hosten wollen. Da musst du dann pro Kunden 400-2.500 $ als Durchlaufposten einkalkulieren.

Zitat:

Zitat von mschaefer (Beitrag 1215038)

Es wäre allerdings gut wenn Embra. sich mal mit diesem Weg beschäftigen würde.

Passen würde es da es auf FMX aufsetzt. Mal schauen ob Emba hier nochmal den Geldbeutel aufmacht (wie beim FMX-Vorläufer bzw. bei FireDAC)

[Bernhard Geyer]

Zitat:

Zitat von Neumann (Beitrag 1215051)

Versuche gibt es einige. Fängt an mit Intraweb, dann noch ETXPascal, Unigui, Raudus und weitere. Raudus funktioniert in seinen Grenzen einigermaßen, ob damit weitergeht weiss man nicht, bei Unigui scheint die Luft raus zu sein und es passiert nichts mehr.

So ein Framework muss ja auch Aspekte wie LoadBalancing, Security, Integrierbarkeit in Portale/SingleSignOn unterstützen wenn es als Weblösung ernst genommen werden will.

Ach ja: Lauffähigkeit auf diversen Non-Windows-Serverplattformen ist auch ein Must. Es gibt genügend Firmen in denen eine Lösung schon deshalb aus der Auswahl fliegt weil sie nur auf Window(Servern läuft). Noch hat man ja das Manko bei XE4 noch.

[Olli73]

Zitat:

Zitat von Neumann (Beitrag 1215051)

bei Unigui scheint die Luft raus zu sein und es passiert nichts mehr.

UniGui wird noch aktiv weiterentwickelt und es funktioniert bereits sehr gut. Allerdings sieht/merkt man davon nichts auf der Homepage, sondern nur wenn man im Forum amgemeldet ist (die aktuellen Versionen gibts auch nur übers Forum).

[rweinzierl]

Zitat:

Zitat von Neumann (Beitrag 1215051)

Versuche gibt es einige. Fängt an mit Intraweb, dann noch ETXPascal, Unigui, Raudus und weitere. Raudus funktioniert in seinen Grenzen einigermaßen, ob damit weitergeht weiss man nicht, bei Unigui scheint die Luft raus zu sein und es passiert nichts mehr.

Intraweb habe ich mal versucht, es schien mir aber sehr instabil zu sein. Vielleicht ist es ja inzwischen brauchbar.

Hallo


Habe mit gerade Raudus angesehen, erstaunlich was es alles gibt, aber mein Ansatz ist anders. (Und zugegeben auf dem ersten Blick ziemlich unlogisch / unsinnig / vogelwild)

Diese Frameworks arbeiten alle wie Delphi für Windows ==> Graphische Komponenten die optisch plaziert werden Eigenschaften und Ereignisse haben (Objektinspektor...).
Nur das eben keine Win32 Elemente rauskommen sondern HTML. ==> Nichts dagegen zu sagen.


Ich möchte jedoch nicht auf diese fertigen Elemente zurückgreifen sondern die Möglichkeiten von HTML5 / Javascript direkter nutzen.
Leider werde ich meine Dialoge nicht mehr zusammenklicken können, sondern quasi mit dem Notepad HTML Formulare entwerfen und dabei Komponenten aus z.B. der jQuery-UI Bibliothek verwenden.
(CSS für die Optik ...)

Wie im ersten Eintrag geschrieben Dialog für Dialog von VCL nach HTML innerhalb meiner EXE.
Die Anwender sollen während der Umstellungsphase also ungebremst weiter arbeiten können.
Die Formularfelder gedenke ich über Javascript/JSON zu füllen und nach Eingabe durch den Anwender so auch wieder auszulesen. (embedded TChromium)

Wenn dann die entscheidenden Dialoge so funktionieren / getestet sind kommt der zweite Teil des Plans dran ( und der ist auch nicht Trivial / Standardvorgehen)
Jetzt will ich die Exe auch auf einem Webserver stellen und mit dem (Apache / ISS ... was auch immer) kommunizieren lassen.
Das was auf dem einzelnen Rechnern dann schon funktioniert jetzt also auch im Web.
Ob jetzt für jeden Anwender meine Exe einmal seperat auf dem Server laufen muss weis ich noch nicht.

So ein vorgehen geht nicht bei einer Webseite mit 100.000 Anwendern aber die werde ich nicht haben.


Ich weis wie sich das Anhört und professionelle Web Entwickler schütteln nur den Kopf aber prinzipiell geht es, und eine bessere Idee habe ich bisher nicht, mal von diversen RDP varianten (Citrix, WebFmx ...) abgesehen.



mfg

Reinhold

[mensch72]

..."Ich möchte jedoch nicht auf diese fertigen Elemente zurückgreifen sondern die Möglichkeiten von HTML5 / Javascript direkter nutzen.
Leider werde ich meine Dialoge nicht mehr zusammenklicken können, sondern quasi mit dem Notepad HTML Formulare entwerfen und dabei Komponenten aus z.B. der jQuery-UI Bibliothek verwenden.
(CSS für die Optik ...) "...


Genau die Fortführung des "RAD" Konzepts für jQuery macht www.CGdevtools.com auf Intraweb Basis.

Im Step1 als "quasi" Standalone EXE einfach ein Delphirahmenprogramm, wo ein TChromium die Anzeige übernimmt und eine IWstandalone Serverkomponente zusätzlich den embedded "WebServer" für alle IW/jQuery Formulare bereitstellt.

Aus "Delphi" Entwicklersicht wird weiter "Form-basiert" programmiert die HTML/jQuery GUI programmiert, auch CSS usw. können eingesetzt werden, wenn man es denn will und kann.

Aus Anwendersicht bleibt es (erstmal) ein normales Programm was gestartet wird und eben eine "moderne" Oberfläche im jQuery Style anzeigt.

Im nächsten Step kann der Standalone WebServer als eingene MultiUser fähige Lösung auf einem (Windows)ZentralServer gestartet werden... in den ClientProgrammen entfällt dann der Serverpart und das Browserfenster verbindet sich nicht mehr mit "localhost", sondern mit dem IW/jQuery ServerProgramm auf dem ZentralRechner. (ist also Client seitig quasi nur eine "URL Änderung")

Im letzten Step kann dann statt einer eigenen Standalone Server EXE auf dem Zentralrechner der Serverpart als ISAPI PlugIn übersetzt werden und dort unter XAMMP/IIS direkt auf/in einem echten Webserver laufen, wenn es denn sein soll.
(Glaskugel: XE8 könnte auch noch etwas mehr in Richtung Linux gehen, dann geht das mit PlugINs auch für "NonWindows";)

Im Prinzip entspricht das exakt der anfänglichen Aufgabenstellung und ist mit CGdevtools + Intraweb für Delphi RAD GUI gewohnte Entwickler am einfachsten StepByStep mit möglichst hoher Wiederverwendbarkeit (von Pascal-Code) zu realisieren.
Für PHP/CSS/HTML5 native Freaks aus der WebDesigner Ecke scheidet sowas halt aus, weil Windows immer gleich MS-Server + IIS und böse;)