dynamische Webseiten - ohne Framework

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Oscar
User
Beiträge: 22
Registriert: Dienstag 25. September 2007, 17:57

Hi,
ich möchte mal etwas in die dynamische Webseitengestaltung einsteigen;
aus verschiedenen Gründen aber ohne Framework. D.h. Editor anschmeißen und
los geht`s. Ein Beispiel:

Code: Alles auswählen

spiel = " bla gegen fasel"
>>> stand = "2 : 4"
>>> c = open("bla.html", "w")
 c.write("""<html>
... <head>
.................
... <body>
... <div id="box">
...        <p>Hier werden später mal die Daten stehen, wie z.B. wer gegen
...        wen spielt: %s <br>
...         oder auch wie der Spielstand ist: %s !</p>
... </div>
... </body>
... </html>""" % (spiel, stand))
>>> c.close()
Meine Frage: ist das so in etwa der richtiige Weg oder geht das auch eleganter? Gibt es
z.B. eine Alternative zur write() Methode oder auch zu der Art von Stringersetzung?

Ich kann mir vorstellen, das es schwierig und unübersichtlich wird, wenn statt zweier
Variablen (oder muß ich Objekte sagen ?) da 42 oder wie viele auch immer stehen.
Ist das dann der Punkt, wo es doch besser ist, ein Framework zu benutzen?

Noch 2 Nebenbemerkungen: Irgendwann wird dann da auch korrekter html-code stehen
und ich weiß, das nicht in aktuell geöffnete Dateien direkt geschrieben werden soll.
Gruß Oscar
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Oscar hat geschrieben:aus verschiedenen Gründen aber ohne Framework.
Fehler Nummer eins. Dann nimm wenigstens Werkzeug, wenn du kein Framework willst.
Oscar hat geschrieben:Meine Frage: ist das so in etwa der richtiige Weg oder geht das auch eleganter?
Was? Auf dem Server statisches HTML generieren? Wenn man dynamische Webprogrammierung will, dann ist das wohl der falsche.
Oscar hat geschrieben:Gibt es
z.B. eine Alternative zur write() Methode oder auch zu der Art von Stringersetzung?
Ja, es gibt eine erweiterte Ersetzung mit ``%(name)type``-Notation, steht in der Anleitung. Zudem gibt es in der Stdlib noch String-Template-Klassen. Aber für sowas solltest du *wirklich* eine Template-Engine nehmen.
Oscar hat geschrieben:Ist das dann der Punkt, wo es doch besser ist, ein Framework zu benutzen?
Das ist auf jeden Fall der Punkt wo man Template-Engines nutzt, sogar schon bevor es 42 %s sind. Sogar schon 23 %s sind 23 zu viele. Der Punkt an dem du ein Framework nutzen solltest, ist der an dem du anfängst dein eigenes zu schreiben. Was in der Regel sehr früh ist.
Oscar hat geschrieben:Noch 2 Nebenbemerkungen: Irgendwann wird dann da auch korrekter html-code stehen
und ich weiß, das nicht in aktuell geöffnete Dateien direkt geschrieben werden soll.
Dann nimm eine Template-Engine die dir validen Code ausspuckt, etwa Genshi. Und wenn du weißt, dass da nicht in eine Datei geschrieben werden soll, dann war das Beispiel sinnlos, weil es nicht darstellt was du zu machen versuchst, sondern nur Stringtemplating demonstriert.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
lunar

Oscar hat geschrieben:ich möchte mal etwas in die dynamische Webseitengestaltung einsteigen; aus verschiedenen Gründen aber ohne Framework.
Ab hier kann man eigentlich aufhören zu lesen, weil man dir aufgrund dieser Voraussetzung sowieso nicht mehr helfen kann.

Der Versuch, ohne auch nur das geringste bisschen Framework dynamische Webprogrammierung zu betreiben, ist wie der Versuch, durch das Springen von einem Berg fliegen zu wollen:

Dem schweren Aufstieg folgt ein schneller, harter und brutaler Fall, der garantiert tödlich endet ;)
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Ich weiss ja nicht aber ich habe schon einige kleine Applikationen als CGI gehackt. Ist nicht elegant oder performant. Aber alle mal kein "harter und brutaler Fall, der garantiert tödlich endet". ;)
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

veers hat geschrieben:Ist nicht elegant oder performant.
Ne, auch nicht einfach (d.h. Anfangs schon, aber im späteren Verlauf verliert CGI). Wenn es komplizierter wird (und dann kann es schnell werden), dann muss man alles selbst machen, das ist eingentlich ein starkes KO-Kriterium gegen CGI. Vor allem da Python echt eine Menge Frameworks hat, da wird sich sicher was passendes finden.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
veers
User
Beiträge: 1219
Registriert: Mittwoch 28. Februar 2007, 20:01
Wohnort: Zürich (CH)
Kontaktdaten:

Leonidas hat geschrieben:Ne, auch nicht einfach (d.h. Anfangs schon, aber im späteren Verlauf verliert CGI). Wenn es komplizierter wird (und dann kann es schnell werden), dann muss man alles selbst machen, das ist eingentlich ein starkes KO-Kriterium gegen CGI. Vor allem da Python echt eine Menge Frameworks hat, da wird sich sicher was passendes finden.
Ja, klar. Aber bei einer grösseren Anwendung würde ich auch kein Framework ala Django verwenden wollen. Da lohnt es sich dann meiner Meinung nach etwas wie Werkzeug zu verwenden und den Rest selber zu machen. :wink:
[url=http://29a.ch/]My Website - 29a.ch[/url]
"If privacy is outlawed, only outlaws will have privacy." - Phil Zimmermann
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

veers hat geschrieben:Ja, klar. Aber bei einer grösseren Anwendung würde ich auch kein Framework ala Django verwenden wollen. Da lohnt es sich dann meiner Meinung nach etwas wie Werkzeug zu verwenden und den Rest selber zu machen. :wink:
Ach, so schlimm ist Django gar nicht. Es ist eben ein Tool für 80% der Fälle. Wenn man es etwas strapaziert (also etwa ORM-Plugins hackt, oder den Admin in einigen Stellen überschreibt) dann kann man auch noch auf 85% kommen. Klar, Werkzeug ist schon toll, aber nicht für alles optimal. Für vieles (und auch für den Einstieg) ist Django besser geeignet. Was teilweise nicht mal an Django selbst liegt, sondern den Mengen an Zusatzpaketen, die es dafür inzwischen gibt.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
lunar

veers hat geschrieben:Ich weiss ja nicht aber ich habe schon einige kleine Applikationen als CGI gehackt. Ist nicht elegant oder performant. Aber alle mal kein "harter und brutaler Fall, der garantiert tödlich endet". ;)
Och.. lass mir doch meine Metaphern ;)
Oscar
User
Beiträge: 22
Registriert: Dienstag 25. September 2007, 17:57

Hi,
gut, es ist schwer in eine Frage alles was relevant ist hineinzupacken.
Zunächst erstmal Danke für Eure Antworten.
Was? Auf dem Server statisches HTML generieren?
Sorry, ich habe vergessen zu erwähnen, das die Daten dann letztlich
aus einer Datenbank kommen. Der obige Code dient erstmal zum rantasten.
Zu meinen Nebenbemerkungen noch mal ein Satz. Mit diesen
Bemerkungen wollte ich eigentlich nur darauf hinweisen, das diese Themen
in diesem Thread nicht wichtig sind - also nicht Diskussionsgegenstand sind.
...harter und brutaler Fall, der garantiert tödlich endet...
Das glaube ich eher nicht und will es auch aus für Euch nachvollziehbaren
Gründen nicht hoffen. :wink:
Zu dem obigen Code nochmal. Der funktioniert ja (und ich lebe auch noch).
Es hat jetzt keiner gesagt, das das pythonisch-programmiertechnisch (booh, was ein Wort)
nicht o.k. ist. Wenn ich jetzt eine Website mit sagen wir mal 5 "Unterseiten" habe,
dann ist das für mich so erstmal praktikabel. Deswegen die Frage, ob das so
o.k. ist (also im eher kleinen Rahmen)?
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Oscar hat geschrieben:Wenn ich jetzt eine Website mit sagen wir mal 5 "Unterseiten" habe,
dann ist das für mich so erstmal praktikabel. Deswegen die Frage, ob das so
o.k. ist (also im eher kleinen Rahmen)?
Also ich habe immer noch das Gefühl dass wenn du die Daten mit Djangos ORM aus der DB ziehst, sie in den Templates renderst und dann mittelst WSGI ausgibst, der Code dann trotzdem noch einfacher, verständlicher und erweiterbarer sein wird als bei CGI.
Oder alternativ das gleiche mit Werkzeug, SQLAchemy und.. sagen wir mal Jinja. Aber Werkzeug gibt dir eben keine feste Struktur vor, wie das Frameworks machen.

Das einzige Problem was ich bei Frameworks sehe ist das Setup. Das ist etwas komplizierter als bei CGI, aber da sollte man auch nicht übertreiben, denn es ist durchaus zu schaffen.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Benutzeravatar
gerold
Python-Forum Veteran
Beiträge: 5555
Registriert: Samstag 28. Februar 2004, 22:04
Wohnort: Oberhofen im Inntal (Tirol)
Kontaktdaten:

Hallo Oscar!

Django und Werkzeug sind ja schon im Spiel. Ich habe mit CherryPy sehr gute Erfahrungen gemacht. Vielleicht kannst du damit etwas anfangen:
- http://halvar.at/python/cherrypy_cheetah/
- http://cherrypy.org/

Auch wenn du auf jedes Framework verzichten möchtest. Auf eine Vorlagensprache würde ich trotzdem bestehen. Vielleicht Cheetah:
- http://halvar.at/python/cheetah_apache_cgi/
- http://www.cheetahtemplate.org/

mfg
Gerold
:-)
http://halvar.at | Kleiner Bascom AVR Kurs
Wissen hat eine wunderbare Eigenschaft: Es verdoppelt sich, wenn man es teilt.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Oscar hat geschrieben:Sorry, ich habe vergessen zu erwähnen, das die Daten dann letztlich aus einer Datenbank kommen.
...
Wenn ich jetzt eine Website mit sagen wir mal 5 "Unterseiten" habe,
dann ist das für mich so erstmal praktikabel. Deswegen die Frage, ob das so
o.k. ist (also im eher kleinen Rahmen)?
Also alle haben schon angedeutet, das es keinen Sinn macht, alles alleine zu machen. Wie bei allen Dingen ist der Limitierende Faktor die Zeit, besser gesagt, deine Zeit.
Ich selber habe auch am Anfang gedacht, ich mache alles selber. Hat auch spass gemacht und man lernt sehr viel. Wenn du allerdings so weiter machst, wirst du irgendwann feststellen, das du dir ein eigenes Framework programmierst. Das war bei mir nicht anders.

Es fängt schon mit der DB API an. Python bietet ja eine Low-Level DB API. Allerdings macht es keinen Sinn, auf dauer mit der Python-DB-API direkt zu interagieren. Man baut also eine Zwischenschicht auf, damit du ständig wiederholende Dinge nicht alle per Hand machen must. z.B. SQL Select Statements aufbauen. Und da haben wir also schon eine DB Layer.

Bei der Template Geschichte wird es nicht anders sein. Denn mit Python Mitteln kannst du z.B. keine Schleifen erstellen. Also Wenn du z.B. variable Anzahl von Punkten aus der DB auflisten möchtest. Also brauchst du dafür irgendwas und beginnst eine TemplateEngine zu basteln.

Vielleicht möchtest du irgendwann mal das man sich in irgendeiner Art einloggen kann. Dann brauchst du ein Session-Managment und eine Userverwaltung.

und es geht immer weiter ;)

Wie gesagt, ich hatte die gleiche Ausgangsbasis, siehe: http://pylucid.org/_goto/70/genesis/#DE

Aber dennoch finde ich es macht durchaus Sinn erstmal mit nichts anzufangen und mit CGI, Python-DB-API so zu spielen. Aber man sollte das gesagte im Hinterkopf behalten und früher oder später auf Frameworks zurück greifen. Ich würde da mir django ansehen ;)

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
mkesper
User
Beiträge: 919
Registriert: Montag 20. November 2006, 15:48
Wohnort: formerly known as mkallas
Kontaktdaten:

jens hat geschrieben:Aber man sollte das gesagte im Hinterkopf behalten und früher oder später auf Frameworks zurück greifen. Ich würde da mir django ansehen ;)
Nur mal so am Rande gefragt: Kann das jemand mit pylons vergleichen?
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

mkallas hat geschrieben:
jens hat geschrieben:Aber man sollte das gesagte im Hinterkopf behalten und früher oder später auf Frameworks zurück greifen. Ich würde da mir django ansehen ;)
Nur mal so am Rande gefragt: Kann das jemand mit pylons vergleichen?
Pylons ist ein großer Haufen Code, der zwar flexibel ist aber IMHO auch nicht viel mehr bietet als etwas Glue-Code. Als ich es mir angeschaut habe, war es recht kompliziert zu nutzen (Paste + etliche weitere Komponenten) da auch irgendwie die Dokumentation gefehlt hat, die einen in eine Richtung geschubst hat. Der Datenbankzugriff war recht seltsam gelöst (SAContext, was es inzwischen nicht mehr gibt), einen richtig großen Vorteil habe ich in Pylons gegenüber dem zusammenpuzzeln von Komponenten habe ich nicht gesehen. Letztendlich habe ich etwas Pylons-ähnliches mit Werkzeug gemacht, da lenkt der Glue-Code IMHO weniger von den einzelnen Komponenten ab. Angeblich soll sich die Dokumentation inzwischen gebessert haben. Inwiefern das der Fall ist weiß ich nicht.

Das neue TurboGears 2 baut auf Pylons auf, eigentlich zurecht, da Pylons konzeptuell recht ähnlich ist.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Oscar
User
Beiträge: 22
Registriert: Dienstag 25. September 2007, 17:57

Hi,
Jens hat geschrieben: Also alle haben schon angedeutet, das es keinen Sinn macht, alles alleine zu machen....
......
Aber dennoch finde ich es macht durchaus Sinn erstmal mit nichts anzufangen und mit CGI, Python-DB-API so zu spielen. Aber man sollte das gesagte im Hinterkopf behalten und früher oder später auf Frameworks zurück greifen.
Das nehme ich mal so als Zusammenfassung an. Dank an alle.
Oscar
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

Mir scheint hier "Frameworks" etwas zu locker genommen zu werden. Als Web-Framework in der Python-Welt verstehe ich Pylons, TurboGears und Django. Alle bestehen aus Komponenten, die entweder (wie bei den ersten beiden) eigenständig sind oder nur im Rahmen des Frameworks erhältlich oder benutzbar sind (trifft für das Meiste bei Django zu).

Für Web-Entwicklung sollte man sich unbedingt Komponenten bedienen. Eine Template-Engine ist *immer* eine gute Idee, praktisch egal, wie wenig Code man erzeugt. Kommt eine Datenbank ins Spiel, entfaltet gerade SQLAlchemy seinen wahren Wert, weil es vom verwendeten DBMS abstrahiert (und damit ein Wechseln ermöglicht) und man kein SQL mehr schreiben muss (was oft sehr ähnlich aussieht, wenn es um die einfachen, gängigen Fälle simpler Abfragen geht), sondern sowas sehr kompakt, flexibel und einheitlich programmatisch in Python formulieren kann.
An weiteren Komponenten Fallen mir da solche für URL-Handling, Sessions, Caching, Formularauswertung und mehr ein.

Ein Framework trifft letztlich meist eine Vorauswahl aus solchen Komponenten und integriert diese mehr oder weniger stark mit ein wenig Glue-Code. Dies mag für 80% der Fälle eine Lösung sein, ist dennoch aber nicht die einzige. Die Komponenten einzeln zu verwenden oder selbst zu integrieren, ist meist sehr einfach und problemlos, dabei zugleich mit mehr Unabhängigkeit und Freiheit verbunden, etwa was Auswahl, Austausch und schrittweises Ergänzen angeht.

Ergo: Ohne Frameworks kommt man auch sehr gut aus, aber man sollte sich schon *sehr* (!) genau überlegen, ob man wirklich nicht auf Komponenten zurückgreift, die die gewollten Wege vereinfachen und optimieren. In Bezug auf eigene Lösungen sollte man sich im Klaren darüber sein, dass man damit praktisch nie an die Qualität von populären und täglich eingesetzten (Open Source-)Produkten heran kommt, die täglich mit Bugreports und Patches verbessert werden.
Benutzeravatar
jens
Python-Forum Veteran
Beiträge: 8502
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Y0Gi hat geschrieben:Die Komponenten einzeln zu verwenden oder selbst zu integrieren, ist meist sehr einfach und problemlos, dabei zugleich mit mehr Unabhängigkeit und Freiheit verbunden, etwa was Auswahl, Austausch und schrittweises Ergänzen angeht.
Das hört sich schön und einfach an. Der Threadstarter hat allerdings gerade erst angefangen...
In der Praxis ist es außerdem alles andere als einfach. Ich denke das beste Beispiel ist Turbogears. Da waren sicherlich einige sehr fähige Leute am Werk. Dennoch gibt es mit der neuen Version ein Bruch, weil die alte Version anscheinend doch nicht so schön war.
Wenn also ein Einsteiger versucht sich mit einigen tollen Komponenten einzudecken und alles zusammen zu kleben, wird es wahrscheinlich in die Hose gehen, würde ich sagen. Dann besser auf unterster Ebene sich die Welt der WebApps anschauen.

Ich denke es ist gerade für Einsteiger vom Vorteil das man gewisse vorgaben an die Hand bekommt und das ist die stärke von django.

GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Leonidas
Python-Forum Veteran
Beiträge: 16025
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

jens hat geschrieben:In der Praxis ist es außerdem alles andere als einfach. Ich denke das beste Beispiel ist Turbogears. Da waren sicherlich einige sehr fähige Leute am Werk. Dennoch gibt es mit der neuen Version ein Bruch, weil die alte Version anscheinend doch nicht so schön war.
Ich habe mich nie richtig für TG erwärmen können, weil es immer irgendwie im Fluss war. 0.7 war nett, 0.8 war damals unfertig und hat eine riesige Menge Dependencies gehabt, so dass ich zu Django gegangen bin, wo sich alles solider anfühlt und nicht ständig wechselt.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Y0Gi
User
Beiträge: 1454
Registriert: Freitag 22. September 2006, 23:05
Wohnort: ja

TG war und ist in meinen Augen ein Prototyp (von den Anfängen mit CP, Kid und SQLObject mal abgesehen), der scheinbar nur an aktuelle Entwicklungen angepasst wird (was an sich ja positiv ist), aber so nie mittel- oder gar langfristig vernünftig einsetzbar ist. Ich betrachte es als eine Art "so würde es aussehen, wenn man es machen würde".
Benutzeravatar
Hyperion
Moderator
Beiträge: 7478
Registriert: Freitag 4. August 2006, 14:56
Wohnort: Hamburg
Kontaktdaten:

Auch wenn's ein wenig offtopic ist, aber kennt jemand etwas ähnliches wie JavaServerFaces für Python? Speziell bei komplexeren Formularen hätte ich da gerne etwas für Python - und für solche Sachen Templates komplett per Hand zu schreiben kann nicht der Weisheit letzter Schluss sein imho.
Antworten