Mittels TChromium Dialoge Dialoge von VCL auf HTML umstellen

[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;)