Python Webprogrammierung Einbindung in HTML?

[mcdaniels]

was ohne Zweifel....

Read the Fabulous Manual heißt THX!

...da gibts noch viel zu lernen und durch meine lange Leitung zu drücken... vor allem muss ich mich vom PHP Ansatz verabschieden, gar nicht so einfach...

[Hyperion]

vor allem muss ich mich vom PHP Ansatz verabschieden, gar nicht so einfach...

Wobei ich das immer noch nicht kapiere! Du hast Dich bis jetzt viel mit Deployment rumgeplagt - was, wie ich ja schon ausführte, imho zu Beginn eher demotivierend ist und auch nicht wirklich produktiv - aber augenscheinlich noch gar nicht mit dem "Erforschen" von Webprogrammierung mittels eines Frameworks. Speziell bei den "Mikro"-Webframeworks kommen dann ja noch andere hinzu, wie Form-Validation-Libs oder ORM.

[mcdaniels]

Korrekt, es hat mich einfach interessiert, wie der Apache zu konfigurieren ist + wie das mit WSGI so läuft. Werde mich aber demnächst nur noch mit bottle beschäftigen. Ich befürchte, dass ich (leider) wieder viele Fragen haben werden.

Fürs "erforschen" reicht dann mal der Develwebserver. (für -vermutlich- sehr lange Zeit...)

Ich komme mir vor wie ein Esel vor dem neuen Scheunentor...

[Hyperion]

Ich kenne jetzt Deine Anwendungsfälle nicht, aber evtl. solltest Du doch mal über Django nachdenken, speziell wenn Du von Rahmenwerken im Webbereich noch keine Erfahrung hast. Bei Django ist quasi alles, was man so braucht, bereits integriert (also ORM, Template Engine, Form Validation und last but not least eine automatisch generierte Admin-Oberfläche) und bestens aufeinander abgestimmt.

Nichts gegen Bottle (oder letztlich auch Flask), aber da muss man sich viele Komponenten dann noch zusätzlich selber zusammen suchen und einbauen. Dass ist dann für einen Anfänger sicherlich noch verwirrender - könnte ich mir zumindest vorstellen

[mcdaniels]

Ists also nicht so wie wenn man gleich mit ner IDE beginnt und so von den basics nicht mit bekommt? Anwendungsfälle... Formularauswertung, mysql Anbindung

[Hyperion]

Ists also nicht so wie wenn man gleich mit ner IDE beginnt und so von den basics nicht mit bekommt?

Eine IDE nimmt einem doch keine Basics weg - sie vereinfacht das Leben. Das Problem bei einer IDE ist deren eigene Komplexität, die einem Anfänger zusätzlich zur eigentlichen Thematik (dem Erlernen einer Sprache) aufgebürdet wird. Bei vielen Sprachen kann man sich eine IDE zu Beginn daher sparen, und diese nach dem Grundverständnis für eine Sprache nutzen.

Bei Django verhält es sich mithin eher anders; gerade weil ein Anfänger oftmals weniger Plan von den besten Libs für eine Aufgabe hat, deren Zusammenspiel nicht unbedingt überschauen kann und dazu ggf. kein Spezialwissen bezüglich der Fallstricke im Webbereich aufweist, hilft es ihm da besonders, wenn er in ein "enges" Korsett gezwungen wird, welches ihm alles, perfekt aufeinander abgestimmt, bietet. Das fängt bei den Komponenten an, führt über die Doku bis hin zu Web-Communities.

Wenn Du Flask mit Mako, MongoDB und FungiForm wählst, dann ist es sicherlich schwierig bei einem Fehler jemanden zu finden, der das in dieser Kombi nachvollziehen kann

Anwendungsfälle... Formularauswertung, mysql Anbindung

Naja, das schreit ja nach einem Full-Stack-Webframework

[mcdaniels]

Na dann werd ich mir morgen mal Django ansehen

[Hyperion]

Also nicht falsch verstehen: Ich will weder Bottle noch Flask schlecht machen - beides sicher tolle Frameworks. Aber für viele Anwendungsfälle fehlt da eben zu viel und genau das macht es dann für den Anfänger komplizierter.

[snafu]

@Hyperion: Ich denke, es ist soweit schon klar, dass man Mikroframeworks nur für "mikroframeworkartige" Aufgaben benutzen sollte oder eben, wenn man sich sozusagen seine eigene Toolchain für die Webentwicklung zusammenschnüren möchte (und vor allem auch weiß, was man tut). Einfach jedem Anfänger zu empfehlen, dass Bottle es schon richten wird, ist sowieso nicht gerade zielführend...

Man kann höchstens sagen: "Ok, ich nehm jetzt z.B. Flask mit seinen Extensions und arbeite mich durch die einzelnen Dokus". Wäre dann halt nicht mehr alles aus einem Guß und man fragt sich am Ende wahrscheinlich, warum man nicht direkt Django benutzt hat.

Django bringt halt nur keinen praktischen `@route`-Dekorator mit, aber ich glaube, das würde man überleben...

[Hyperion]

Django bringt halt nur keinen praktischen `@route`-Dekorator mit, aber ich glaube, das würde man überleben...

Naja, ob man nun einen Dekorator "braucht" wage ich auch zu bezweifeln. Bevor Armin Flask aus der Taufe hob, habe ich auch schon mit Werkzeug kleinere Sachen gemacht; da hatte ich die Routen auch in einer einzigen Map an zentraler Stelle Aber was mir wirklich bei Werkzeug (und darauf aufbauenden Libs) gefällt, ist die Syntax für Routingdefinitionen! Mit RegExps in diesem Kontext mag ich mich nicht so anfreunden...

[mcdaniels]

Hallo,
erster Eindruck von Django -> ... alles neu, alles anders... und mächtig! Gibts da u.a. eine Buchempfehlung oder sollte man sich da an die Webresourcen halten?

[Hyperion]

Also ich würde versuchen, erst einmal das Tutorial durch zu *arbeiten*. Ich denke damit kommst Du schon recht weit

[mcdaniels]

Ich bin grade in der ... Orientierungsphase. Die kommt bei mir nach der "oh mein Gott ich bin erschlagen Phase" . Kommt Zeit kommt (dank Tutorial) hoffentlich auch Rat.

Django scheint ja wirklich einiges selbst in die Hand zu nehmen. (Man muss ja nich mal die SQL Kommandos selbst basteln )

[Hyperion]

Django scheint ja wirklich einiges selbst in die Hand zu nehmen. (Man muss ja nich mal die SQL Kommandos selbst basteln )

Das muss man bei Bottle oder Flask auch nicht; nur musst Du dafür dann das SQL-Framework "SQLALchemy" bemühen - Django bringt seinen eigenen "ORM" (= object relational mapper) inkl. SQL-Abstraktionsschicht mit.

Daran siehst Du vielleicht, womit ich bei einem meiner Postings hinaus wollte, als ich schrieb, dass man sich bei den Mikro-Frameworks um viele selber kümmern muss.

[DasIch]

Man kann höchstens sagen: "Ok, ich nehm jetzt z.B. Flask mit seinen Extensions und arbeite mich durch die einzelnen Dokus". Wäre dann halt nicht mehr alles aus einem Guß und man fragt sich am Ende wahrscheinlich, warum man nicht direkt Django benutzt hat.

Wenn ich Flask hat mit Jinja2 imho eine bessere Template Engine als Django. SQLAlchemy ist imho besser als das ORM von Django und flatland ist imho ebenfalls besser als Form Library. Klar hab ich die Funktionalität prinzipiell mit Django schon aber sich für ein Microframework zu entscheiden nur weil es kleiner ist, ist genauso lächerlich wie zu sagen es wäre sinnvoll Frameworks zu haben die nur aus einer Datei bestehen.

[deets]

Was die Micro Frameworks (bottle benutze ich selbst) aber nicht haben ist eine große, engagierte Community. Und das ist bei django eine großes plus. Nicht, weil das programmieren damit besser wäre. In Gegenteil, da ist viel Schatten. Aber einfach zb ein CMS einklinken zu können, das ist ein wichtiger Punkt. Natürlich nicht für jede Seite. Aber schon für viele.

Ich selbst ziehe rein technisch TurboGears2 oder Pyramid vor - aber zumindest ersteres ist Community-Wise fast tot. Und Pyramid hat auch noch nicht den Dampf dahinter.

[Dav1d]

Die Flask-Community würde ich nicht als klein bezeichnen, z.Z. befinden sich 273 Leute in #Pocoo auf Freenode, viele davon nutzen Flask (DasIch verbessere mich, wenn ich falsch liege).

[Leonidas]

Die Flask-Community würde ich nicht als klein bezeichnen, z.Z. befinden sich 273 Leute in #Pocoo auf Freenode, viele davon nutzen Flask (DasIch verbessere mich, wenn ich falsch liege).

Also 10% der Django Community? 1% der Django Community? Ich stimme zwar auch zu, dass Django seine Schattenseiten hat (so finde ich die Templatesprache unzumutbar, aber man kann die auswechseln), dennoch für Anfänger ist die Struktur von Django ein großes Plus. Ich mein, der OP (no offense) wusste nicht dass es ORMs gibt. Wie lange würde es dauern bis der OP die Absicherungen gegen XSS, CSRF, Clickjacking etc entdeckt, die Django einfach so schon mitbringt?

[snafu]

Klar hab ich die Funktionalität prinzipiell mit Django schon aber sich für ein Microframework zu entscheiden nur weil es kleiner ist, ist genauso lächerlich wie zu sagen es wäre sinnvoll Frameworks zu haben die nur aus einer Datei bestehen.

Den Einwand verstehe ich nicht so ganz. Was ist daran lächerlich, ein Mikroframework zu benutzen, weil man die Aufgeblähtheit von Django vermeiden will, wenn die Aufgabenstellung diesen Umfang nicht erfordert?

Wie schon gesagt: MFs gehen aber genau so auch für komplexere Projekte. Dann hat man sich meist bewusst für die Individualität des eigenen Zusammenstellens entschieden (oder bewusst für die angebotenen Extensions) oder aber das Projekt ist nach und nach auf Grundlage eines Mikroframeworks mitsamt zusätzlich eingebundener Bibliotheken gewachsen.

Mir ist halt nicht wirklich klar, worauf du hinaus willst...

Achso, und One-File-Frameworks (sprich: Bottle) haben zumindest den Vorteil, dass sie mal eben ins Entwicklungsverzeichnis kopiert, statt installiert werden können. Je nach Umgebung kann sowas manchmal wichtig werden. Ansonsten finde ich hinsichtlich der Übersicht, Wartbarkeit, Verständlichkeit des Codes usw eine Aufteilung in Module ebenfalls besser. Da geht Bottle halt seinen eigenen Weg. Die "Lächerlichkeit" dessen möchte ich aber bezweifeln.

[mcdaniels]

...der OP (no offense) wusste nicht dass es ORMs gibt

Seh ich nicht als offense, keine Angst . Bin halt kein hauptberuflicher DB Entwickler oder Programmierer und habe mich noch nicht mit Frameworks beschäftigt.

Diverse Angriffsszenarien jedoch, kenne ich schon. Deren "Umschiffung" in Python jedoch, ist wieder ein anderes Thema .

Ich werfe hier mal ein: Django bringt diese Absicherungen mit. Als Anfänger bekommt man davon dann allerdings nichts mit. Einerseits gut, dass Django davor schützt, andererseits aber auch wieder nicht, da der Anfänger dann nicht weiß, wie er das abseits von Django zu handhaben hat.

Wenn die Thematik jedoch so komplex ist, dass ein Anfänger ohnehin damit komplett überfordert ist, dann macht das Django meiner bescheidenen Meinung nach richtig. Ich bin mittlerweile mitten im Tutorial. Es ist (für mich) schon eine gewaltige Umstellung, muss ich sagen.

Meine "Projekte" (wenn man das so nennen kann) waren in php nie so groß, dass man tatsächlich auf div. Frameworks zurückgreifen musste.

Beim Thema Sicherheit und PHP drehte sich mir dann der Magen um... Ich hab das damals (und es ist schon viel zu lange her) so lange exzessiv verfolgt, bis mir der Spaß daran vergangen ist. (Wer kann mit Sicherheit sagen, dass das Programm, Script etc. wasserdicht ist...?, ..hat man was übersehen, was ist, wenn etwas in die Hose geht...)

Schließlich und endlich bin ich dann von der idealistischen Idee, mir selbst ein CMS zu schreiben auf Joomla "umgestiegen" (Wieso das Rad neu erfinden...)

Ich glaube jedenfalls, dass in Zukunft (ein dehnbarer Begriff) python php überholen wird.

LG
Daniel