Anwendung Netzwerkfähig machen

[Achtzig]

1) Wenn man bei der Entwicklung WebKit einbindet und dort den HTML-Text ausgibt, ist das Debuggen kein Problem, da ja kein Server dazwischen steht.
2) Das muß man bei PHP auch. Für Lazarus gibt wohl auch einen Konverter von Konventionell zu HTML. Habe ich aber nie ausprobiert, weil ich was eigenes habe. Außerdem gibt es wohl auch ein Frame-Work - ebenfalls noch nicht ausprobiert.
3) Bei PHP ist das nicht anders. HTTP ist normal ein zustandsloses Protokoll. Der Client stellt eine Anfrage, der Server beantwortet sie - fertig. Die Verbindungen werden nie lange aufrecht erhalten.
4) Ich verstehe jetzt nicht wirklich, wo da der Unterschied zu PHP ist. Das eine Webanwendung keine normale Desktopanwendung ist und somit anders programmiert werden muß, ist klar. Aber ob der Webserver die Anfragen nun an ein PHP-Programm weiterreicht oder an ein CGI-Programm macht für mich keinen Unterschied.

Nachtrag. Oh, ich bin viel zu langsam

[m.fuchs]

Aber grafisches Erstellen einer Browser-basierten GUI und Debuggen von Web-Anwendungen (CGIs etc) ist mit Lazarus - soweit ich weiß - quasi nicht möglich. Ob es da besseres gibt, weiß ich aber auch nicht. (Siehe auch obiger Beitrag.)

Grafisches Erstellen von Webanwendungen ist aber IMHO sowieso nicht der richtige Weg. In PHP ist es eigentlich nicht vorgesehen, Microsoft hat sich mit ASP.NET MVC auch von solchen Ansätzen verabschiedet.

Zum Debuggen kann ich TFPHTTPServer empfehlen. Wenn du das LazWebExtra-Package installierst, hast du ein eigenes Projekt namens "HTTP server application". Das ist dann ein Stand-Alone-Webserver, in dem du dein Webmodul entwickelst. Da kannst du auch bequem drin debuggen. Wenn du fertig bist, machst du dir ein neues CGI-Projekt, hängst dein Modul rein und gut ist es.
(Siehe auch hier: http://opensoft.homeip.net/articles/webserver1.pdf)

[mschnell]

Das debuggen von Webanwendungen kann man wunderbar mit Lazarus.

Hört sich gut an. Wie geht denn das ?
(Nach Lesen der anderen Beiträge: Offensichtlich durch temporäres Einbauen eines Webservers in die Applikation: nicht schön, aber vermutlich machbar.)

Es gibt auch Tools um Formulare in html umzuwandeln, somit stimmt die Aussage mit den GUIś auch nicht ganz.

Hört sich gut an. ich glaube aber nicht dass das tatsächlich sinnvoll möglich ist, Wie geht denn das ?

Die Aussage das irgendwas im Webanwendungsbereich mir Lazarus nicht so umfangreich ist ist schlichweg humbug.
Du hast mit Lzarus mehr Möglichkeiten als mit php.

Das mag sein. Ob das aber reicht ist eine andere Frage (php kenne ich nur vom lesen diverser Beiträge in diversen Foren) ...

Bitte poste doch mal ein (Sourcecode) Beispiel für ein CGI, das z.B. hinter einem Apache Server auf einem x86 Linux installierbar ist (dann könnte ich es möglicherweise testen, ich bin aber nicht sicher, ob mein Provider das tatsächlich zulässt). Im Beispiel soll einfach jede Sekunde eine Zahl auf der Browser-GUI (die aus einem Delphi Formular konvertiert wurde) inkrementiert werden. Das Projekt soll so aufgebaut sein, dass man daraus - unter Befolgung einer klaren Anleitung - sowohl ein normales GUI Programm als auch die besagte Web-Applikation kompilieren kann.

Du kannst selbst deinen Webserver direkt mit in deine Anwendung kompilieren.

Genau das will man bei Web-Applikationen nicht. Der Kunde verlangt, dass die Applikation "hinter" einem "normalen" Webserver läuft (Apache oder IIS).

-Michael

[mschnell]

ist das Debuggen kein Problem, da ja kein Server dazwischen steht.

OK. Die strategie wäre also mit (durch Webkit) "eingebautem" HTTP-Server zu debuggen und für das Release ohne diesen Zusatz zu kompilieren. Nicht toll, aber vermutlich machbar.

HTTP ist normal ein zustandsloses Protokoll. Der Client stellt eine Anfrage, der Server beantwortet sie - fertig. Die Verbindungen werden nie lange aufrecht erhalten.

Genau,. Deshalb ist es zum Aufbau einer ernsthaften GUI sehr schlecht geeignet. Es gibt Tools die helfen können (EXTJS, EXTPASCAL und Protokoll-Spezialitäten, die das (Offenlassen einer Verbindung über den Webserver so lange wie möglich) unterstützen ("Comet"). Ist aber alles andere als unproblematisch.

4) Ich verstehe jetzt nicht wirklich, wo da der Unterschied zu PHP ist. Das eine Webanwendung keine normale Desktopanwendung ist und somit anders programmiert werden muß, ist klar.

Wie gesagt, habe Ich php erwähnt, weil ich gelesen habe, dass es genau dazu da ist (nicht weil ich behaupten wollte, dass es tatsächlich besser geeignet ist).

Wie gesagt, ist die Zielrichtung des Lazarus Teams vordringlich die "normale GUI Applikation. Ich bin da schon oft genug mit meinen Wünschen / Vorschlägen (für Anwendungen mit "embedded" Charakter) auf ziemlich taube Ohren gestoßen. Begründung: 99 % der Lazarus - User machen ausschließlich normale GUI Anwendungen, deshalb investieren wir unsere knappen Ressourcen nur dafür.

-Michael

[mschnell]

Grafisches Erstellen von Webanwendungen ist aber IMHO sowieso nicht der richtige Weg.

Das mag wohl sein. Es gibt ja noch nicht einmal einen wirklich guten freien WYSIWIG HTML-Editor also erst recht kein Tool um so eine Seite dann komfortabel mit "Leben" zu füllen.

Ich verwende momentan den inzwischen freien Microsoft Expression Web 4. Aber zufrieden bin ich damit ganz und gar nicht.

-Michael

[Achtzig]

Der Aufbau einer "funktionalen" Oberfläche ist nur im Zusammenhang mit JavaScript möglich. Wenn Du kein eigenen Webserver betreiben sollst aber dennoch ein Programm ständig laufen soll, bleibt aus meiner Sicht eigentlich nur ein Dämon übrig, der die Daten bereitstellt.

1) JS sendet Polling-Anfrage an den Webserver.
2) Webserver gibt die Daten an ein kleines Programm weiter.
3) Das Programm gibt die Anfrage an den ständig laufenden Dämon weiter.
4) Der Dämon gibt die Antwort an das Programm zurück.
5) Das Programm gibt die Daten aus.
6) Der Webserver beendet das Programm und die Verbindung.

Eine Verbindung "so lange wie möglich" offen zu halten wäre mir zu unkontrolliert.

[mschnell]

Der Aufbau einer "funktionalen" Oberfläche ist nur im Zusammenhang mit JavaScript möglich. Wenn Du kein eigenen Webserver betreiben sollst aber dennoch ein Programm ständig laufen soll, bleibt aus meiner Sicht eigentlich nur ein Dämon übrig, der die Daten bereitstellt.

1) JS sendet Polling-Anfrage an den Webserver.
2) Webserver gibt die Daten an ein kleines Programm weiter.
3) Das Programm gibt die Anfrage an den ständig laufenden Dämon weiter.
4) Der Dämon gibt die Antwort an das Programm zurück.
5) Das Programm gibt die Daten aus.
6) Der Webserver beendet das Programm und die Verbindung.

Genau so machen meine Kollegen das ja auch. (Mit Delphi / ISAP / ISS / Windows). (Kleine Erweiterung: mit "FCGI" (Apache) oder "ISAPI" (ISS) kann das "kleine Programm" weiter im Hintergrund warten und muss (im Normalfall) nicht neu gestartet werden. Das erhöht (besonders unter Windows) die Perormance erheblich.)

Es geht aber auch ohne den zusäztlichen Dämon. Das macht zum Beispiel ExtJS. Mit EXTPascal kann man darüber hinaus mit VLC/LCL die Oberflächen gestalten (dafür gibt es dann eine eingeschränkte Anzahl von entsprechend ausgelegten visuellen Komponenten, die meist den "normalen" GUI Komponenten ähnlich sind und beim Editieren auch so funktionieren. Ich weiß nicht ob EXTPascal noch ein "aktives" Projekt ist (alle Welt benutzt ja (leider) php für solche Anwendungen).

In beiden Fällen ist aber eine Meldung des Programms an die Oberfläche nicht ohne unverhältnismäßigen Polling Overhead möglich, weil die Verbindung ja immer wieder geschlossen wird..

Eine Verbindung "so lange wie möglich" offen zu halten wäre mir zu unkontrolliert.

Das macht "Comet" indem das Javascript Applet im Browser regelmäßig (jede Minute oder so) pollt, um die Verbindung offen zu halten oder neu zu öffnen, falls sie zusammengebrochen ist (weil der Webserver sie beendet hat). Comet kann dann da wieder aufsetzen.

"Sauber" ist das nicht, aber HTTP ist eben ein blödsinniges Protokoll, das nur dazu da ist, unnötigen Overhead und unnötige Schwierigkeiten zu erzeugen.

-Michael

[Christian]

Man muss keinen Webserver in die Applikation einbauen o.ä.
Eine Webanwendung die Serverseitig läuft ist entweder direkt ein Webserver oder ein CGI oder ein FastCGI oder ein Apache Modul.

Wenn man die Applikation als Webserver betreibt (THTTPApplication) kann man einfach im Browser drauf zugreifen (localhost:8080)
Wenn man die Applikation als CGI oder FastCGI betreibt (TCGIApplication,TFCGIApplication) kann man einen Apache zwischenschalten der eine weiterleitung zum CGI oder FastCGI macht (fastcgiexternalserver cgi-bin/MeineApp –host localhost:2014 –idle-timeout 3)
Mit Apache Modul kenn ich derzeit keine Möglichkeit heisst aber nicht das es keine gibt.

Mit https://code.google.com/p/extpascal/ kann man auch Forms direkt im Designer entwickeln und die Applikation als CGI oder fCGI kompilieren.

[mschnell]

Man muss keinen Webserver in die Applikation einbauen o.ä.
Wenn man die Applikation als Webserver betreibt (THTTPApplication) ....

Das meinte ich mit "Webserver einbauen"

Wenn man die Applikation als CGI oder FastCGI betreibt (TCGIApplication,TFCGIApplication) ...

Dann startet Apache das Programm "irgendwann". Wie kann der Lazarus Debugger es dann "fangen" um auf einen Breakpoint zu reagieren ?

-Michael

[m.fuchs]

Wenn man die Applikation als CGI oder FastCGI betreibt (TCGIApplication,TFCGIApplication) ...

Dann startet Apache das Programm "irgendwann". Wie kann der Lazarus Debugger es dann "fangen" um auf einen Breakpoint zu reagieren ?

Du kannst das Programm bitten einen Debugger zu starten (http://wiki.lazarus.freepascal.org/CGI_ ... ugging_CGI). Trotzdem würde ich immer den oben beschrieben Weg benutzen, ein extra Debugging-Projekt mit internen Webserver zu erstellen. Ist sehr bequem.

Das debuggen von Webanwendungen kann man wunderbar mit Lazarus.

Hört sich gut an. Wie geht denn das ?
(Nach Lesen der anderen Beiträge: Offensichtlich durch temporäres Einbauen eines Webservers in die Applikation: nicht schön, aber vermutlich machbar.)

Warum nicht schön? Einfach ein extra Projekt für das Debuggen anlegen und gut ist es. Bei größeren Anwendungen hat man sowieso mehrere Lazarus-Projekte: Hauptprogramm, einen kleines Kommandozeilentool zu schnellen testen, Unittest-Projekt(e), allerlei Hilfstools und nun halt noch einen Debuggingprojekt.