Offline-Ajax (ohne Webserver)

[droptix]

Soll eine Windows-Anwendung mit Browser-Oberfläche entwerfen. Dachte an PortableFirefox, HTML und dynamische Inhalte über Ajax und Python.

Problem: Es soll kein Webserver laufen. Bleibt nur noch der Python-Interpreter (python.exe).

Ziel: Über JavaScript und XMLHttpRequest wird ein Python-Script angesprochen und Daten werden übermittelt. Das Python-Script soll die Daten empfangen, auswerten/berechnen und eine Antwort als HTML-Code für den XMLHttpRequest liefern.

Geht das überhaupt? Es müsste ja eine TCP/IP-Verbindung über Sockets sowie die HTTP-Verbindung gefaked werden, oder?

[tiax]

bei Python ist der SimpleHTTPServer in der Standard-Bibliothek dabei, vielleicht taugt dir das ja

[droptix]

Naja, das ist ja quasi ein kompletter HTTP-Server. Die Frage ist, ob das technisch überhaupt geht... also XMLHttpRequest baut ja eigentlich eine HTTP-Verbindung auf. In meinem Fall gibt es ja keinen HTTP-Server, also dürfte eigentlich keine Verbindung zustande kommen. Vielleicht kann man die aber vortäuschen?

[lunar]

So pauschal: Nein.

[droptix]

Woran scheitert's?

Hum, könnte man im Python-Script temporär einen HTTP-Server starten, ihn über Sockets an Port 80 binden, die gesendeten Daten vom HTML-Formular als RAW-Daten empfangen (sys.stdin?), in einen HTTP-Request wandeln und an den HTTP-Server übergeben, die Antwort generieren und in Reintextform zurück schicken? Anschließend den HTTP-Server stoppen und alles killen?

[Leonidas]

Wo ist das Problem, das Skript einfach einen HTTP-Server mitlaufen zu lassen?

[Y0Gi]

Browser-Oberfläche, aber kein Webserver? Ist da nicht ein Denkfehler drin?

Kannst du die Restriktion "kein Webserver" näher erläutern oder evtl. sogar begründen?

[gerold]

Über JavaScript und XMLHttpRequest wird ein Python-Script angesprochen und Daten werden übermittelt. Das Python-Script soll die Daten empfangen, auswerten/berechnen und eine Antwort als HTML-Code für den XMLHttpRequest liefern.

Hallo droptix!

Natürlich geht das. Python hat einen eingebauten XMLRPC-Server. Python hat aber auch einen eingebauten HTTP-Server. Verabschiede dich von dem Gedanken, dass ein Webserver so etwas wie ein Apache sein muss. Siehe: http://www.python-forum.de/topic-5478.html

Wenn ich so etwas machen müsste, dann würde ich keine Zeit damit verplempern, die HTML-Seiten vom Python-Programm zu trennen. Ich würde auch die HTML-Seiten von Python ausliefern lassen. Dann kannst du viel in Python erledigen, was auf der Client (Browser) Seite vielleicht umständlicher ist.

Und noch etwas. Ich würde sofort auf ein Vorlagensystem wie z.B. Cheetah oder Jinja setzen. Das hat nur Vorteile.
Und schrieb ich schon, dass ich CherryPy für so etwas empfehlen würde?

mfg
Gerold


PS: In etwa so, oder so ähnlich:

Code: Alles auswählen

#!/usr/bin/env python
# -*- coding: iso-8859-15 -*-

import cherrypy
from cherrypy._cptools import XMLRPCController 
import webbrowser


class Root(object):
    
    def index(self):
        return "Hallo Welt"
    index.exposed = True
    

class XmlRpc(XMLRPCController):

    def reversed_text(self, text):
        return {"text": text[::-1]}
    reversed_text.exposed = True 


def main():
    root = Root()
    root.xmlrpc = XmlRpc()
    webbrowser.open_new_tab("http://localhost:8080/")
    cherrypy.quickstart(root)


if __name__ == "__main__":
    main()

Die XMLRPC-Methode ``reversed_text`` ist über ``http://localhost:8080/xmlrpc/reversed_text`` erreichbar.

.

[lunar]

Woran scheitert's?

Das man "Verbindungen" nicht einfach "emulieren" kann ... du brauchst nun mal einen Server, der auf der Gegenseite lauscht.

Hum, könnte man im Python-Script temporär einen HTTP-Server starten, ihn über Sockets an Port 80 binden, die gesendeten Daten vom HTML-Formular als RAW-Daten empfangen (sys.stdin?), in einen HTTP-Request wandeln und an den HTTP-Server übergeben, die Antwort generieren und in Reintextform zurück schicken?

Das ist doch genau das, was der eingebaute Webserver von Python tut (abgesehen davon, dass man für Port 80 Admin-Rechte braucht)? Wo liegt denn eigentlich dein Problem?

[gerold]

Hallo droptix!

Eines wollte ich noch los werden: Ich habe vor ein paar Jahren genau so programmiert. Ich dachte, dass es eine super Lösung sei, Zope als lokalen Serverunterbau zu verwenden und Erweiterungen zu meinem Programm auf HTML-Basis zu erstellen.

Es hat sich aber schon nach wenigen Monaten herausgestellt, dass es eine ziemlich schlechte Lösung war. Die Kunden verlangten immer wieder nach Lösungen, die auf HTML-Basis nur sehr schwer zu programmieren waren oder schlecht in den vorhandenen Workflow integriert werden konnten.
Auch wenn es anfänglich sehr verlockend schien. Es hat sich herausgestellt, dass es für mich viel einfacher ist, die Wünsche der Kunden mit einem GUI-Framework wie wxPython umzusetzen.

mfg
Gerold

[jens]

Ich denke es wird langsam sein. Auch wenn noch kein Verbindungsstück zwischen Python und dem Browser existiert, denken wir doch mal wie das ablaufen kann, wenn kein Server da ist.

Der Browser schickt eine Anfrage los und irgendwas starten einen Python Interpreter, der ein das Ergebnis eines Skripts zurück zum Browser liefert.

Das hört sich nach CGI ohne Apache an

[Leonidas]

Ich denke es wird langsam sein. Auch wenn noch kein Verbindungsstück zwischen Python und dem Browser existiert, denken wir doch mal wie das ablaufen kann, wenn kein Server da ist.

Ne, das müsste dann ein lokaler HTTPd sein, wie ihn jedes Framework mitliefert.

Das hört sich nach CGI ohne Apache an

Jedes mal den Webserver starten hört sich noch viel schlimmer an. Überleg dir mal, wenn bei jedem Request erstmal der HTTPd hochgefahren wird, dieser wiederrum ein CGI startet, das beendet, der HTTPd den Output des CGIs zurückschickt und dann herunterfährt. Davon mal abgesehen dass das eben nicht geht, weil wenn der HTTPd nicht läuft, dann kommt auch keine Verbindung zustande.

[droptix]

Das Programm läuft ohne Adminrechte, daher gestaltet sich eben ein echter Server über Ports schwierig. Da es auch portabel sein soll, kann man nicht auf einen fest vorinstallierten HTTP-Server vom System zurückgreifen.

Ich brauche eine portable, einfache GUI, daher die Idee via HTML. Außerdem beherrsche ich wxPython nicht so gut. Hab mich mal mit wxGlade abgequält, aber damit kriege ich sicher nicht das hin was ich mir vorstelle.

Weiteres Thema: mit dem Starten der Anwendung (also in meiner Idee PortableFirefox) soll kein zweites Fenster aufgehen. Man könnte sicher noch den Server mit einer GUI starten und das Fenster dann verstecken... aber wie schließt man es?

Dass Python jede Menge tolle Sachen wie SimpleHTTPServer oder XMLRPCServer mitbringt ist mir klar, aber damit komme ich wieder auf das Zweite-Fenster-Problem.

--

Was ja funktioniert: Wenn ich via XMLHttpRequest auf eine Textdatei zugreife, die HTML-Code beinhaltet, dann kann ich damit arbeiten.

Bleibt die Frage, ob ich die Anfrage statt an eine Textdatei an ein Python-Script senden kann, welches der Anfrage einen künstlichen Textdatei-Stream samt Header (Content-type: text/plain) zurück gibt? Vielleicht über diese StringIO-Dinger? Dann brauch ich das Thema Server und Sockets nicht mehr.

Das Problem wird aber sein, dass das Python-Script wahrscheinlich nicht ausgeführt wird, oder?

[Leonidas]

Das Programm läuft ohne Adminrechte, daher gestaltet sich eben ein echter Server über Ports schwierig. Da es auch portabel sein soll, kann man nicht auf einen fest vorinstallierten HTTP-Server vom System zurückgreifen.

Würde mich wundern. Bei Unices braucht man nur root-Rechte wenn man Ports < 1024 öffnen will, wäre erstaunt wenn unter anderen Systemen sockets noch weiter eingeschränkt wären.

Weiteres Thema: mit dem Starten der Anwendung (also in meiner Idee PortableFirefox) soll kein zweites Fenster aufgehen. Man könnte sicher noch den Server mit einer GUI starten und das Fenster dann verstecken... aber wie schließt man es?

Einfach den Python-Prozess mit ``pythonw`` starten, dann geht kein Fenster für Python auf.

Dass Python jede Menge tolle Sachen wie SimpleHTTPServer oder XMLRPCServer mitbringt ist mir klar, aber damit komme ich wieder auf das Zweite-Fenster-Problem.

Nein.

Bleibt die Frage, ob ich die Anfrage statt an eine Textdatei an ein Python-Script senden kann, welches der Anfrage einen künstlichen Textdatei-Stream samt Header (Content-type: text/plain) zurück gibt? Vielleicht über diese StringIO-Dinger? Dann brauch ich das Thema Server und Sockets nicht mehr.

Das Problem wird aber sein, dass das Python-Script wahrscheinlich nicht ausgeführt wird, oder?

Das könntest du höchstens machen wenn du ein Overlay-Dateisystem hast bei dem bei jedem Dateizugriff versucht wird die Datei auszuführen. Aber das wird auch nicht richtig funktionieren weil ja die Skripte irgendeine Eingabe brauchen.

Mir ist deine Ablehnung des eingebauten HTTP-Servers immer noch völlig unklar. Statt da irgendwelche seltsamen Workarounds zu bauen, versuch es doch einfach erstmal auf dem einfachen Weg.

[droptix]

Mir ist deine Ablehnung des eingebauten HTTP-Servers immer noch völlig unklar. Statt da irgendwelche seltsamen Workarounds zu bauen, versuch es doch einfach erstmal auf dem einfachen Weg.

Ich verstehe eure Auffassung dazu, aber ich möchte recht schnell einen Prototypen mit GUI entwickeln... und GUI-Entwicklung in Python lernt man nicht mal eben schnell. Wenn's nur um ein Fenster mit ein paar Knöpfchen geht ist das kein Problem... aber in meinem Fall wird's schon komplexer. Sprich ich traue mir das in der kurzen Zeit nicht zu.

Ich habe noch was hübsches gefunden: http://www.drweb.de/magazin/html-application-hta/. Kannte ich schon, hab das aber nie in Erwägung gezogen.

Damit kann ich eine GUI in HTML schreiben und habe aber Benutzerrechte und kann auf das Dateisystem zugreifen. Ich kann damit auch Befehle ausführen und auch auf StdOut zugreifen:

Code: Alles auswählen

strTarget = "127.0.0.1"
Set objShell = CreateObject("WScript.Shell")
Set objExec = objShell.Exec("ping -n 2 -w 1000 " & strTarget)
strPingResults = LCase(objExec.StdOut.ReadAll) 

Hier auch noch interessante Beispiele.

[jens]

Ich kann dich schon verstehen. GUI Entwicklung ist auch nicht so mein Ding.

Wenn es allerdings schnell gehen soll, dann nimm doch einfach django und den vorhandenen Dev.Server für den Prototypen. Den Port kannst du ja auf > 1024 legen.
Der Dev.Server kann auch statische Dateien ausliefern, was du sicherlich auch brauchen wirst, siehe: http://docs.djangoproject.com/en/dev/ho ... tic-files/