WSGI ist nichts anderes als PHP

[daemonTutorials]

Na gut, für PHP gibt es auch Frameworks(PEAR, Zend) aber das tut hier nichts zur Sache.

Ich verstehe es nicht, warum die meisten Sagen, man solle ein Framework wie Django, etc. nehmen.
Dabei ist WSGI doch nicht so schwer. Wer mal PHP programmiert hat, weiß was ich meine.

WSGI sind die Grundlagen. Und es ist angenehm damit eine Webanwendung zu entwickeln.
Dafür muss man das Admin-Interface allein schreiben, aber das ist egal. Hauptsache man hat eine individuell angepasste Webanwendung.

Da PHP auf das Internet ausgelegt ist, ist es nicht weiter wunderlich, dass 2 Zeilen PHP Code gleich 15 Zeilen Python Code bedeuten. Aber auf größere Webanwendungen gesehen, ist Python genauso.

Für Projekte, wo man mit dem Django-Admin-Interface zufrieden ist, ist ja alles gut. Aber für individuell gestaltete Webanwendungen mit Framework-fremden oder annormalen DB-Design, ist eine rudimentäre WSGI-Webanwendung doch das beste. Eventuell kann man noch SQLAlchemy dazu nehmen. Aber das ist ja ein anderes Thema.

Ich sage: "WSGI macht mir mehr Spaß, als dass ein Framework die ganze Arbeit erledigt."

[DasIch]

WSGI hat sehr viele kleine Details die man nicht mal eben so richtig implementiert. Dazu kommt das richtige parsen und validieren der form Daten usw. Das ist sehr schwer richtig und fehlerfrei zu implementieren und alles andere als angenehm.

Bei dem Code den du bisher abgeliefert hast bezweifle ich dass du überhaupt in der Lage bist einzuschätzen wie schwer es überhaupt ist und wo die Probleme liegen.

Zu sagen dass PHP auf das Internet ausgelegt ist sagt übrigens gar nichts aus, mal völlig abgesehen dass PHP ein ganz schlechtes Vergleichskriterium zu irgendwas ist. Ich bewerte die Arbeit eines Klempners ja auch nicht nach der Arbeit meines Nachbaren der davon "jede Menge Ahnung" hat.

[deets]

@daemonTutorials

Was du da erzaehlst ist ziemlicher Unfug. PHP & WSGI sind beide im Webumfeld angesiedelt. Und da hoert dann die Gemeinsamkeit schon auf.

WSGI bietet kein Templating, keine Abstraktion von POST/GET-Variablen und erst recht keine Anbindung an Datenbanken oder andere externe Resourcen (inklusive des Filesystems), welches alles PHP bietet - und auch die ganzen Webframeworks.

Es ist dir unbenommen, "pures" WSGI zu benutzen, das kann und wird dir keiner verbieten. Aber es als ausreichend im Sinne von "mehr braucht keiner" fuer die Webentwicklung zu bezeichnen ist falsch. Es ist eine auf Python gemuenzte Variante von Web-Anwendungs-Anbindung wie das CGI (es teilst sich nicht umsonst die letzten beiden Buchstaben damit), und erstaunlich gut geeignet, kompositionale Webentwicklung zu foerdern - man klaubt sich Request/Response-Abstraktion, Transaktions-Management, Session-Management, URL-Space-auf-Code-Abbildung bis hin zu Authorisation/Authtentifizierung von Benutzern aus dem Middleware-Regal.


Doch jede Webanwendung basierend auf WSGI zieht diese Abstraktionen ein, und wird damit das eigene Framework.

Und was das "nicht so schwer" angeht - die ganzen Feinheiten von zB form-encodierten oder multipart-encodierten Requests mit den dazugehoerigen Unicode-Themen korrekt zu codieren, das ist schon ein ganz schoenes Stueck Arbeit, und *danach* ist man erst bei dem Komfort, dem einem sowas wie Bottle oder die grossen Framowerks bieten.

[/me]

Bei dem Code den du bisher abgeliefert hast bezweifle ich dass du überhaupt in der Lage bist einzuschätzen wie schwer es überhaupt ist und wo die Probleme liegen.

Wenn in der "Umfrage" SQLAlchemy und Jinja als Frameworks bezeichnet werden, dann zeigt sich mir hier schon deutlich die Wissensgrenze des Fragers.

[jens]

Für Projekte, wo man mit dem Django-Admin-Interface zufrieden ist, ist ja alles gut. Aber für individuell gestaltete Webanwendungen mit Framework-fremden oder annormalen DB-Design, ist eine rudimentäre WSGI-Webanwendung doch das beste. Eventuell kann man noch SQLAlchemy dazu nehmen. Aber das ist ja ein anderes Thema.

Django bietet wesentlich mehr als nur das Admin Interface.

[Defnull]

Ganz abgesehen davon ist PHP ein Framework. Wenn man gemein ist, könnte man auch sagen, PHP ist eine etwas bessere Template Sprache. Denn im Endeffekt ist es nichts Anderes.

Ich halte die Aussage auf der PHP Homepage, PHP sei eine "general-purpose scripting language" für eine Marketing-Lüge. Wenn über 90% der Funktionalitäten auf Web-Entwicklung ausgelegt wind und man sie nur per Compiler-Flags vom Sprachkern lösen kann, ist das keine "general-purpose" Sprache. Genau so gut könnte man Desktop-Anwendungen mit Mako oder Jinja schreiben. Klar, es geht, aber warum sollte man das tun?

</rant>

[daemonTutorials]

Oh, SQLAlchemy und Jinja2 sind echt keine Frameworks. Upps!

Okay, PHP kann ich nicht mit Python vergleichen.

Aber was WSGI angeht. Wieso sollte man etwas mit Unicode tun? Die DB-Anbindung geht über die entsprechenden Module! Außerdem kann man die transkodierten doch mit ein paar Funktionen dekodieren.

In PHP ist das so, nur das dort die transkodierten schon von PHP dekodiert werden.(Aber ich wollte ja nicht mit PHP vergleichen, sry)

Okay, SessionManagement ist nicht mit drin. Da habt ihr recht. Gibt es denn ein Framework was sich nur zum SessionManagement dreht?

Außerdem finde ich Django und Konsorten zu unflexibel. Dort wird ein Projekt gestartet und alles automatisch angelegt. Das ist doch irgendwie dumm.

Gut, ich verwende weiter WSGI und bin damit fröhlich.

[/me]

Aber was WSGI angeht. Wieso sollte man etwas mit Unicode tun? Die DB-Anbindung geht über die entsprechenden Module! Außerdem kann man die transkodierten doch mit ein paar Funktionen dekodieren.

Ich würde jedem empfehlen, in aktuellen Programmen intern ausschließlich mit Unicode zu arbeiten. Es gibt für mich keinen Grund dafür, das nicht zu tun. Warum sollte ich mich auf die Verarbeitung von ASCII oder ISO-8859-15 beschränken wollen?

Außerdem finde ich Django und Konsorten zu unflexibel. Dort wird ein Projekt gestartet und alles automatisch angelegt. Das ist doch irgendwie dumm.

Ich empfinde es eher als praktisch, wenn ich elementare Dinge automatisch erstellt bekomme. Man muss sich natürlich schon ein paar Stunden einarbeiten um grundlegende Kenntnisse des Frameworks zu erhalten und um erkennen zu können, was das Framework tatsächlich leistet. Es hindert dich beispielsweise keiner daran, eine Django-Anwendung komplett ohne Datenbankzugriff zu schreiben.

Dein Problem scheint zu sein, dass dir Frameworks, wie der Name schon sagt, einen gewissen Rahmen vorgeben. Das magst du nicht und möchtest anderes verwenden. Du kannst dann Leichtgewichte wie Bottle verwenden oder natürlich direkt auf WSGI aufsetzen. Ich passe mich lieber einer zum Teil vorgegebenen Struktur an und habe es dadurch leichter.

[lunar]

Zudem gilt immer noch das, was DasIch bereits gesagt hat. Es ist nicht einfach, direkt an der WSGI-Schnittstelle zu programmieren, da man viel wissen muss, nicht nur über WSGI, sondern auch über HTTP selbst. Ich halte es mit DasIch und maße mir an, dem OP angesichts seiner bisherigen Beiträge zu unterstellen, dass ihm dieses Wissen und die nötige Erfahrung fehlt. Insofern bezweifele ich stark, dass der OP nur mithilfe von WSGI korrekte Anwendungen zu schreiben in der Lage ist, und ich bezweifele auch, dass der OP noch immer nur WSGI nutzen würde, wenn er wüsste, was man dafür alles wissen muss.

[deets]

Aber was WSGI angeht. Wieso sollte man etwas mit Unicode tun? Die DB-Anbindung geht über die entsprechenden Module! Außerdem kann man die transkodierten doch mit ein paar Funktionen dekodieren.

In PHP ist das so, nur das dort die transkodierten schon von PHP dekodiert werden.(Aber ich wollte ja nicht mit PHP vergleichen, sry)

Ich weiss nicht, was die "transkodierten" sind. Ich rede von HTTP - das hat nichts mit einer Datenbank zu tun. Welches encoding haben die Daten, die reinkommen? Dekodierst du das sauber zu unicode? Jetzt mal schnell & ohne zu schummeln: woran erkennst du das encoding von angelieferten Formulardaten, und wie spezifizierst du genau das Encoding von deinen produzierten Inhalten?

Okay, SessionManagement ist nicht mit drin. Da habt ihr recht. Gibt es denn ein Framework was sich nur zum SessionManagement dreht?

Fuer einen grossen Befuerworter von WSGI kennst du dich ja nicht so doll aus. In der WSGI-Lingo sind das keine Frameworks, sondern Middlewares. Und es gibt so manche, uA Beaker fuer session-management. Welches wiederum von Pylons/TG2 verwandt wird.

Außerdem finde ich Django und Konsorten zu unflexibel. Dort wird ein Projekt gestartet und alles automatisch angelegt. Das ist doch irgendwie dumm.

Wenn etwas dumm ist, dann diese Aussage. Denn bestenfalls hast du eine geschaecklerische Aussage getaetigt. Aber nicht belegt, was "unflexibel" ist. Dazu muesstest du schon sagen "dies und jenes geht so und so einfach in WSGI, aber mit Django ist es voll doll schwer." Die Tatsache, dass Django eine Menge Dateien anlegt hat damit ja erstmal nix zu tun. Und andere Frameworks (bottle zb) legen *garkeine* Dateien fuer dich an.

Also, wo ist WSGI flexibler als Django?

[Dauerbaustelle]

*Popcorn*

[daemonTutorials]

Middlewares? Muss mir mal die Definition angucken.
Session-Management brauche ich momentan nicht. Daher die Bemerkung.
Ich frage die Daten so ab, wie sie reinkommen. An die evtl. Umkodierung habe ich nicht gedacht.
Da muss ich mal gucken. Besonders bei Umlauten sollte ich die DB auf utf-8 stellen, den HTTP-Server auf utf-8 und das HTML-charset auf utf-8.

Danke!

[Leonidas]

Session-Management brauche ich momentan nicht. Daher die Bemerkung.

Also abstrahierst du von deiner Situation auf alle anderen? Viele Leute brauchen Sessions. Wenn du keinen Datenbankzugriff brauchst - viele Leute brauchen Datenbankzugriff. Ich kann jetzt auch nicht sagen dass dadurch dass meine Homepage aus statischen HTML-Seiten besteht, keiner dynamisch generiere Seiten braucht. Das ist duoch offensichtlischer Quatsch.

Ich frage die Daten so ab, wie sie reinkommen. An die evtl. Umkodierung habe ich nicht gedacht.

Also arbeitest du mit Bytestrings, die abwechselnt UTF-8, ISO-8859-15 und CP1215 sind? Na super

Ich halte es mit DasIch und lunar. Zudem dein Thread-Titel keinen Sinn macht und in diesem Kontext auch die Umfrageoptionen Quatsch sind. konnte nichtmal eine Option anklicken weil es einfach so bizarr war.

[noisefloor]

Hallo,

zusammenfassend kann man also sagen: reines WSGI wil niemand verwenden - außer, man will "Yet another WSGI framework" schreiben

@daemonTutorials: Wenn du nacktes WSGI verwenden willst - warum nimmst du dann für die DB-Anbindung ein Framework wie SQLAlchemy. Nacktes SQL funktioniert doch auch...

Gruß, noisefloor

[daemonTutorials]

Ich nehme ja "nacktes" sql mit sqlite3!
Für Py3 gibt es ja keine mysql anbindung, oder?

[daemonTutorials]

Ich seh schon, das führt zu nix gutes. Ich bitte die Moderatoren dieses Thema zu schließen.

[BlackJack]

@daemonTutorials: Es gibt auch für Python 3.x eine MySQL-Anbindung: http://packages.python.org/oursql/

Gleich der erste Punkt auf der Webseite behandelt übrigens das was ich gerade in einem anderen Thread geschrieben habe: Die Trennung von SQL und den Daten.

[noisefloor]

Hallo,

doch, gibt es: http://code.google.com/p/pymysql/ und https://launchpad.net/oursql/py3k

Gruß, noisefloor