Hallo Gerold,
dein Tutorial ist wirklich gut und ich habe dadurch wieder einiges gelernt.
Trotzdem habe ich noch ein paar Fragen.
In der INI Datei hast du reale Ordner für css und images festgelegt. Das ist logisch, aber was ist mit Ordnern wie "my1stsubdir" o. "my2ndsubdir"?
Ich habe es bisher nämlich so verstanden das die Ordnerstruktur aus der URL auf Klassen und Funktionen zurück zu führen ist und nicht auf reale Ordner.
Ist es in dem Fall möglich über die URL auf diese realen Ordner zuzugreifen oder passiert das gar nicht über die URL?
Wie und wofür nutzt du die realen Ordner?
Meine zweite Frage ist, wie und ob es möglich ist CherryPy hinter einem Apache oder Lighttpd Server zu nutzen?
Die Frage stellt sich mir weil CherryPy ja wie aus deinem Tutorial zu entnehemen ist einen eigenen Server auf macht.
Du hast bisher immer alle Klassen in einer Datei dargestellt. Natürlich ist es in einem Tutorial einfacher für die Darstellung oder ist das so Standart bei CherryPy das alles in einer Datei gespeichert wird?
mfg snatch
Erfahrungsbericht: CherryPy und Cheetah
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hallo snatch!
Genau diese, schon vielfach bewährte Arbeitsweise will ich mir nicht durch einen Web-Applikationsserver durcheinander bringen lassen. Natürlich ist CherryPy so ausgelegt, dass es den URL aus dem Tree -- den Klassen und Methoden unterhalb des Root-Objekts -- zusammensetzt. Aber auch dann, wenn ich in CherryPy eine Methode habe, die für z.B. die Kontaktseite zuständig ist, dann wird es bei mir im Dateisystem immer auch einen logisch zugehörigen Ordner geben, in dem alle Bilder für diese Kontaktseite gespeichert sind.
Dann gibt es noch einen Grund für die realen Ordner im Dateisystem. In meinem Erfahrungsbericht arbeite ich mit Cheetah-Templates. Und ich habe die CherryPy-Anwendung so umgeschrieben, dass immer dann wenn zu einem URL keine zugehörige Methode gefunden werden kann, die Anwendung im zum URL gehörenden Ordner im Dateisystem nach einer Cheetah-Template sucht und diese anzeigt.
So ist es möglich, den größten Teil der Website aus einzelnen Cheetah-Templates zu erstellen, ohne auch nur eine einzige Zeile Code der CherryPy-Anwendung ändern zu müssen. Man erstellt einfach einen neuen Ordner und legt dort die Cheetah-Templates und die Bilder rein. Fertig!
- http://www.cherrypy.org/wiki/WSGI
- http://projects.amor.org/misc/wiki/ModPythonGateway
- http://code.google.com/p/modwsgi/wiki/I ... thCherryPy
Jede Klasse einfach so in eine eigene Datei zu speichern bringt keine Vorteile. Also mache ich es auch nicht. Es ist in Python nicht üblich, Programme komplizierter zu machen als sie sein müssten.
mfg
Gerold
Wenn ich z.B. Bilder in einer HTML-Seite verwende, die nur in diese eine Seite gehören, dann speichere ich die Bilder dieser HTML-Seite in den gleichen Ordner, in dem auch die HTML-Seite gespeichert ist. Ich habe mir angewöhnt, den meisten HTML-Seiten einen eigenen Ordner im Dateisystem zu gönnen. So habe ich immer eine abgeschlossene Einheit für sich. Eine HTML-Seite mit allen zugehörigen Bildern. Will ich diese Seite los werden, dann lösche ich diesen Ordner mit all seinen Bildern. Möchte ich die HTML-Seite unter einem anderen URL zur Verfügung stellen, dann verschiebe ich den Ordner mit all seinen Bildern.snatch hat geschrieben:In der INI Datei hast du reale Ordner für css und images festgelegt. Das ist logisch, aber was ist mit Ordnern wie "my1stsubdir" o. "my2ndsubdir"? Ich habe es bisher nämlich so verstanden das die Ordnerstruktur aus der URL auf Klassen und Funktionen zurück zu führen ist und nicht auf reale Ordner. Ist es in dem Fall möglich über die URL auf diese realen Ordner zuzugreifen oder passiert das gar nicht über die URL?
Wie und wofür nutzt du die realen Ordner?
Genau diese, schon vielfach bewährte Arbeitsweise will ich mir nicht durch einen Web-Applikationsserver durcheinander bringen lassen. Natürlich ist CherryPy so ausgelegt, dass es den URL aus dem Tree -- den Klassen und Methoden unterhalb des Root-Objekts -- zusammensetzt. Aber auch dann, wenn ich in CherryPy eine Methode habe, die für z.B. die Kontaktseite zuständig ist, dann wird es bei mir im Dateisystem immer auch einen logisch zugehörigen Ordner geben, in dem alle Bilder für diese Kontaktseite gespeichert sind.
Dann gibt es noch einen Grund für die realen Ordner im Dateisystem. In meinem Erfahrungsbericht arbeite ich mit Cheetah-Templates. Und ich habe die CherryPy-Anwendung so umgeschrieben, dass immer dann wenn zu einem URL keine zugehörige Methode gefunden werden kann, die Anwendung im zum URL gehörenden Ordner im Dateisystem nach einer Cheetah-Template sucht und diese anzeigt.
So ist es möglich, den größten Teil der Website aus einzelnen Cheetah-Templates zu erstellen, ohne auch nur eine einzige Zeile Code der CherryPy-Anwendung ändern zu müssen. Man erstellt einfach einen neuen Ordner und legt dort die Cheetah-Templates und die Bilder rein. Fertig!
CherryPy basiert auf WSGI und das ist ein Standard der es ermöglicht, die Anwendung entweder als eigenständigen Server oder auch hinter einem Apachen oder Lighttpd laufen zu lassen.snatch hat geschrieben:wie und ob es möglich ist CherryPy hinter einem Apache oder Lighttpd Server zu nutzen?
- http://www.cherrypy.org/wiki/WSGI
- http://projects.amor.org/misc/wiki/ModPythonGateway
- http://code.google.com/p/modwsgi/wiki/I ... thCherryPy
Mehrere Dateien zu benutzen, bringt nur dann einen Vorteil, wenn du mit anderen Python-Modulen interagieren musst. Wenn das nicht der Fall ist, dann verkompliziert jede zusätzliche Datei dein Programm ohne weiteren Zusatznutzen.snatch hat geschrieben:Du hast bisher immer alle Klassen in einer Datei dargestellt. Natürlich ist es in einem Tutorial einfacher für die Darstellung oder ist das so Standart bei CherryPy das alles in einer Datei gespeichert wird?
Jede Klasse einfach so in eine eigene Datei zu speichern bringt keine Vorteile. Also mache ich es auch nicht. Es ist in Python nicht üblich, Programme komplizierter zu machen als sie sein müssten.
mfg
Gerold
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
-
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Wobei mod_wsgi ähnliche Designfehler wie mod_python hat, zumindest der 'embedded mode'. Den Interpreter im Apache-Prozess (oder überhaupt im HTTPd-Prozess) laufen lassen ist Aufgrund der Eigenschaften des Python-Interpreters nicht anzuraten. Letztendlich bleibt der 'daemon mode', der zwar weniger Setup benötigt als FastCGI/SCGI, aber im Gegensatz zu diesen fest an Apache gekoppelt ist. Besser als mod_python ist es schon und vielleicht wird es ja besser betreut als Apaches FastCGI Module. Ansonsten sollte man erstmal abwägen, was man benötigt.gerold hat geschrieben:CherryPy basiert auf WSGI und das ist ein Standard der es ermöglicht, die Anwendung entweder als eigenständigen Server oder auch hinter einem Apachen oder Lighttpd laufen zu lassen.snatch hat geschrieben:wie und ob es möglich ist CherryPy hinter einem Apache oder Lighttpd Server zu nutzen?
- http://www.cherrypy.org/wiki/WSGI
- http://projects.amor.org/misc/wiki/ModPythonGateway
- http://code.google.com/p/modwsgi/wiki/I ... thCherryPy
Achja, CherryPy kann man auch sicherlich noch durch mod_proxy laufen lassen, vor WSGI war das recht populär, denke ich.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Der Zugriff auf reale Ordner ist dann aber nicht über die URL möglich, oder? Ich verstehe das doch richtig das du die realen Unterordner nur in Functionen also im Code an sich benutzt, es wäre dann also nicht möglich das man über die URL in einen realen Unterordner kommt, oder?
Das du eine Funktion geschrieben hast die eine URL überprüft und dann guckt ob ein Ordner oder eine Datei mit dem Namen verfügbar ist, habe ich wahrgenommen, aber wie ist das wenn man keine Funktion dafür schreibt? Ich gehe davon aus das man dann einen Error bekommt das die jeweilige Funktion nicht vorhanden ist. Oder denke ich da Falsch?
Dann noch eine Sache zu den Classen. Du hast schon recht das man Code so einfach wie möglich machen sollte, aber ich finde wenn man Module auf verschiedene Klassen und somit auch auf verschiedene Dateien aufteilt, hat man ein besser übersicht. Möglich ist es ja immer noch in der Root Klasse die anderen Klassen aus anderen Dateien zu importieren.
mfg snatch
Das du eine Funktion geschrieben hast die eine URL überprüft und dann guckt ob ein Ordner oder eine Datei mit dem Namen verfügbar ist, habe ich wahrgenommen, aber wie ist das wenn man keine Funktion dafür schreibt? Ich gehe davon aus das man dann einen Error bekommt das die jeweilige Funktion nicht vorhanden ist. Oder denke ich da Falsch?
Dann noch eine Sache zu den Classen. Du hast schon recht das man Code so einfach wie möglich machen sollte, aber ich finde wenn man Module auf verschiedene Klassen und somit auch auf verschiedene Dateien aufteilt, hat man ein besser übersicht. Möglich ist es ja immer noch in der Root Klasse die anderen Klassen aus anderen Dateien zu importieren.
mfg snatch
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hallo snatch!snatch hat geschrieben:wie ist das wenn man keine Funktion dafür schreibt? Ich gehe davon aus das man dann einen Error bekommt das die jeweilige Funktion nicht vorhanden ist.
Probiere es doch aus.
mfg
Gerold
PS: Nein, wenn man das im Quellcode nicht vorsieht oder einen Ordner nicht ohne Einschränkung mit "tools.staticdir.on" markiert, dann kommt man nicht von außen auf den realen Ordner zu.
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Hallo Gerold!
Erstmal danke, für den schönen Bericht über eine der schönsten Bibliotheken fürs Web.
Ich arbeite mit CherryPy auch schon seit dem Release der Version 2.2 und bin immer überzeugter.
Wenn man sich nicht zu viel in den Kern hacken muss, ist es eine wunderbare Sache, gehts weit unter die Haube muss man schauen, ob halt Bibliotheken, wie Werkzeug, Colubrid oder Paste nicht besser währen.
Wobei auch hier CherryPy mit den `tools` sehr starke Anpassungen erlaubt.
Was mich allerdings interessiert, ist die Möglichkeit eines eigenen Dispatchers, für meine Applikation, da ich gerne meine Applikationen etwas anders aufbauen möchte, als mir der aktuelle es zulässt. (ohne hässliches Hacken von diesem)
Kennst du dazu gute Dokumentationen/Beispiele.
Zur Zeit habe ich nur die halbwegs gute Dokumentation aus dem Quellcode gelesen und gehe einfach mal davon aus, das man nur `cherrypy.request.handler` auf ein `callable object` setzen muss und die Konfigurationsmöglichkeiten mit einbezieht, sofern dies in der entsprechenden API vorgesehen ist (ich erinnere an `handler._cp_config`).
Kennst du da noch etwas anderes?
MfG EnTeQuAk
Erstmal danke, für den schönen Bericht über eine der schönsten Bibliotheken fürs Web.
Ich arbeite mit CherryPy auch schon seit dem Release der Version 2.2 und bin immer überzeugter.
Wenn man sich nicht zu viel in den Kern hacken muss, ist es eine wunderbare Sache, gehts weit unter die Haube muss man schauen, ob halt Bibliotheken, wie Werkzeug, Colubrid oder Paste nicht besser währen.
Wobei auch hier CherryPy mit den `tools` sehr starke Anpassungen erlaubt.
Was mich allerdings interessiert, ist die Möglichkeit eines eigenen Dispatchers, für meine Applikation, da ich gerne meine Applikationen etwas anders aufbauen möchte, als mir der aktuelle es zulässt. (ohne hässliches Hacken von diesem)
Kennst du dazu gute Dokumentationen/Beispiele.
Zur Zeit habe ich nur die halbwegs gute Dokumentation aus dem Quellcode gelesen und gehe einfach mal davon aus, das man nur `cherrypy.request.handler` auf ein `callable object` setzen muss und die Konfigurationsmöglichkeiten mit einbezieht, sofern dies in der entsprechenden API vorgesehen ist (ich erinnere an `handler._cp_config`).
Kennst du da noch etwas anderes?
MfG EnTeQuAk
- gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hallo EnTeQuAk!EnTeQuAk hat geschrieben:Was mich allerdings interessiert, ist die Möglichkeit eines eigenen Dispatchers, für meine Applikation, da ich gerne meine Applikationen etwas anders aufbauen möchte, als mir der aktuelle es zulässt.
Damit habe ich mich noch nicht befasst. Vielleicht findest du hier etwas:
- http://www.cherrypy.org/search?q=dispatcher&wiki=on
- http://www.cherrypy.org/wiki/ConfigAPI# ... thonsyntax
- http://www.cherrypy.org/wiki/WSGI
- http://www.cherrypy.org/wiki/CherryPySpec
Ich weiß nur, dass man sich selber einen Dispatcher bauen und diesen über die Config zuweisen kann.
lg
Gerold
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Ok, der Link zur CherryPySpec hat mir dann doch weitergeholfen, da ist einiges drinne, was sonst nirgentwo dokumentiert ist.
Wen es interessiert, einen halbwegs konformen Dispatcher mit Werkzeugs (http://werkzeug.pocoo.org) URL Ruting einzusetzen, der schaue sich den folgenden Code an:
Nun, da ich also kein richtiges 'root' Objekt verwende sondern verteilte `Views`, habe ich mir überlegt, was brauche ich dann ein Application-Objekt, das an cherrypy.tree.mount übergeben wird. Keine Ahnung, aber ich brauchte zumindest eines, das so aussieht:
Das muss reichen und so funktioniert es auch.
Für Fragen stehe ich gerne offen, da ich nun halbwegs Ahnung davon habe
MFG EnTeQuAk
Wen es interessiert, einen halbwegs konformen Dispatcher mit Werkzeugs (http://werkzeug.pocoo.org) URL Ruting einzusetzen, der schaue sich den folgenden Code an:
Code: Alles auswählen
#-*- coding: utf-8 -*-
import cherrypy
from werkzeug import routing
from wwws.views import all_views
from wwws.urls import url_map
class WWWSDispatcher(object):
"""
Because we don't use the default
dispatcher this will be the real
internal application.
"""
def __init__(self):
self.url_map = url_map
self._views = all_views.copy()
def get_view(self, endpoint):
return self._views[endpoint]
def __call__(self, path_info):
req = cherrypy.request
print dir(req)
url_adapter = self.url_map.bind_to_environ(req.wsgi_environ)
try:
endpoint, args = url_adapter.match(path_info)
except routing.NotFound:
req.handler = cherrypy.NotFound()
except routing.RequestRedirect, e:
req.handler = cherrypy.HTTPRedirect()
else:
view = cherrypy.dispatch.LateParamPageHandler(
self.get_view(endpoint))
req.handler = view
#: set the request config
req.config = cherrypy.config.copy()
#: It's not needed from cherrypy but we also return
#: the page handler object.
return req.handler
Code: Alles auswählen
class Application(object):
_cp_conf = {'request.dispatcher': WWWSDispatcher(),
'tools.trailing_slash.on': False,
'tools.wsgiapp.on': True,
}
Für Fragen stehe ich gerne offen, da ich nun halbwegs Ahnung davon habe
MFG EnTeQuAk
Wenn du das gleiche meinst, wie ich, ist es sogar im Kern implementiert:
http://cherrypy.org/browser/trunk/cherr ... ch.py#L227
Inzwischen habe ich noch einige aktualisierungen angebracht. Die sind aber eher trivial und dienen der einhaltung der `CherryPySpec`. Ist ja auch nicht gerade ohne, die erstmal durchzuarbeiten
MfG EnTeQuAk
http://cherrypy.org/browser/trunk/cherr ... ch.py#L227
Inzwischen habe ich noch einige aktualisierungen angebracht. Die sind aber eher trivial und dienen der einhaltung der `CherryPySpec`. Ist ja auch nicht gerade ohne, die erstmal durchzuarbeiten
MfG EnTeQuAk