Ja, ich weiß, ein leidiges Thema. Aber ich muss doch nochmal fragen.
Ich wühle mich seit ein paar Tagen durch diverse Webgeschichten in Python, sowohl fertige Projekte wie Webshops, als auch Frameworks. Ich habe auch alles mal grob angetestet, um mir einen Einblick zu verschaffen, darunter Werkzeug, Pylons, Turbogears und Django.
Was bei Django ganz nett ist ist die automatische Erzeugung des Admin Interfaces. Was mich stört steht mehr oder weniger in den Kritiken im Python Wiki. Insbesondere die langen Patch Zeiten, das mittelmäßige ORM und eine ebenfalls mittelmäßige Template Engine. Ich hab da die Befürchtung, zwar schnell einen Anfang zu haben, aber auch schnell Grenzen zu finden.
Mich würde auch mal interessieren wieso Django (in diesem Forum) so verbreitet ist. Ist es das "Convenience Food"? Und wieso führt Turbogears so ein Schattendasein?
Turbogears vs. Django
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Also die Template-Engine (was mein Hauptproblem war und zu den meisten Frustrationen führte) lässt sich ziemlich einfach und schmerzlos durch Jinja2 ersetzen und ansonsten ist es nicht so schlimm wie immer behauptet wird. Die langsame Entwicklung ist natürlich Tatsache aber das ORM ist einfach zu nutzen und - seien wir mal ehrlich - in der Regel durchaus ausreichend. Was für kranke Queries planst du denn zu machen wenn du die ganze Komplexität von SQLAlchemy ins Boot holen willst?burli hat geschrieben:Was bei Django ganz nett ist ist die automatische Erzeugung des Admin Interfaces. Was mich stört steht mehr oder weniger in den Kritiken im Python Wiki. Insbesondere die langen Patch Zeiten, das mittelmäßige ORM und eine ebenfalls mittelmäßige Template Engine. Ich hab da die Befürchtung, zwar schnell einen Anfang zu haben, aber auch schnell Grenzen zu finden.
Django ist "gut genug" für, na sagen wir mal 80% aller Projekte, eher noch mehr. Dadurch dass es gut dokumentiert ist (sowohl Online als auch inzwischen in Papierform) und eine durchaus beachtliche Community hat ist der Einstieg einfacher als bei anderen Frameworks. Zudem ist es vergleichsweise kompatibel, d.h eine Seite die ich vor einiger Zeit geschrieben habe, funktioniert idR. auch mit nur minimalen Anpassungen genauso in der aktuellsten Django 1.2 beta.burli hat geschrieben:Mich würde auch mal interessieren wieso Django (in diesem Forum) so verbreitet ist. Ist es das "Convenience Food"? Und wieso führt Turbogears so ein Schattendasein?
Turbogears hat das Problem, dass sie immer auf tote Pferde setzen: SQLObject, Kid, CherryPy etc. Später steigen sie auf irgendwas anderes um und der alte Code ist für die Tonne. Zudem alles wesentlich weniger wie aus einem Guss wirkt. TG 2.0 geht schon eher in eine richtige Richtung, aber wenn ich so bedenke dann bewegt sich TG 2.0 am ehesten noch in die Richtung in der es sich selbst zugunsten von Pylons obsolet macht.
Und durch das ganze tauziehen an der TurboGears-Front wurden viele User vergrault, so dass viele bei Django sind und die coolen Sachen jetzt eher selten bei TG anzutreffen sind.
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Danke für die Meinung. Klingt so, als verderben bei TG zu viele Köche den Brei.
Das weiß ich nicht. Was für Queries müsste man denn auffahren, um den Django ORM zu überfordern?Leonidas hat geschrieben:Was für kranke Queries planst du denn zu machen wenn du die ganze Komplexität von SQLAlchemy ins Boot holen willst?
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Würde ich nicht machen. Der Schritt von den Django-Templates zu Jinja ist nicht so groß und wer weiß, vielleicht reichen dir Djangp-Templates ja. Schließlich nutzen alle Django-Erweiterungsprojekte ja auch die Django-Templates.burli hat geschrieben:Ich hätte noch eine Frage. Sollte ich gleich zu Beginn Jinja in Django verwenden? Also gar nicht erst mit der Django-eigenen anfangen?
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Ich kann keine qualifizierte Aussage zu TurboGears treffen, da ich das nicht kenne. Zu Django möchte ich anmerken, dass ich den ORM gut finde und sein Ruf hier in der Vergangenheit schlechter gemacht wurde als angemessen wäre. Ich war vor einiger Zeit echt erstaunt, dass das so viel gelobte ActiveRecord von Rails 2.3 (noch) weniger kann als Djangos ORM. Propaganda ist alles. Bei der Template-Engine finde ich nur doof, dass es unverhältnismäßig aufwendig ist, neue Tags zu bauen und es nervt, diese immer mit `load` in jedem Template zu laden (was man aber umgehen kann). Ansonsten kann ich das Urteil "mittelmäßig" nicht nachvollziehen. Für Django spricht der Umfang und die Qualität der Dokumentation und die Größe der Community. Mir scheint der Markt- (sprich Aufmerksamkeits-) Anteil von TG verschwindend gering gegenüber Django. Gleiches gilt für andere Rahmenwerke. Für Django spricht IMHO auch, dass es ein "Fullstack" ist, d.h. eine Komplettlösung, mit der man sofort loslegen kann, ohne vor eine verwirrende Auswahl von Alternativen gestellt zu werden, für die man am Anfang einer Entwicklung keine Kompetenz hat, sie zu treffen. Hier will man von der Erfahrung anderer profitieren. Genau aus diesem Grund wählt man ja ein Rahmenwerk. Das ist der selbe Grund, warum immer noch Rails gegenüber all dem anderen Stückwerk im Ruby-Umfeld dominiert.
Wenn sich die Aufgabe irgendwie in das große diffuse Gebiet des Content-Management (also klassische "Webweiten" bauen) einordnen lässt, ist Django IMHO eine gute Lösung, mit der man schnell und effizient zum Ziel kommt.
Ich habe es die letzten drei Jahre gerne (wenn möglich) eingesetzt - gerade wenn ich Aussagen wie "den Prototyp baue ich dir in einem Tag" gegenüber Kollegen die aus ihrer Java-Welt kommend (man, ich habe Spring inzwischen echt satt) da eher in Wochen rechnen wahr machen musste. Ein Fake-Shop-System mit Demo-Daten in 4 Stunden? Kein Problem. Schnell ein Datenmodell definiert, ein Admin-UI konfiguriert und los geht es. Dann noch ein paar Views und Templates (was meist am längsten dauert) und fertig ist der Demo-Shop.
Für zukünftige Projekte werde ich mich dennoch wohl eher Ruby und Rails 3 zuwenden. Ich möchte mehr über dieses Rahmenwerk lernen und es besser vergleichen können. Außerdem, gestehe ich gerne, sagt mir die Innovations- und Experimentierfreude der Ruby-Community mehr zu.
Stefan
Wenn sich die Aufgabe irgendwie in das große diffuse Gebiet des Content-Management (also klassische "Webweiten" bauen) einordnen lässt, ist Django IMHO eine gute Lösung, mit der man schnell und effizient zum Ziel kommt.
Ich habe es die letzten drei Jahre gerne (wenn möglich) eingesetzt - gerade wenn ich Aussagen wie "den Prototyp baue ich dir in einem Tag" gegenüber Kollegen die aus ihrer Java-Welt kommend (man, ich habe Spring inzwischen echt satt) da eher in Wochen rechnen wahr machen musste. Ein Fake-Shop-System mit Demo-Daten in 4 Stunden? Kein Problem. Schnell ein Datenmodell definiert, ein Admin-UI konfiguriert und los geht es. Dann noch ein paar Views und Templates (was meist am längsten dauert) und fertig ist der Demo-Shop.
Für zukünftige Projekte werde ich mich dennoch wohl eher Ruby und Rails 3 zuwenden. Ich möchte mehr über dieses Rahmenwerk lernen und es besser vergleichen können. Außerdem, gestehe ich gerne, sagt mir die Innovations- und Experimentierfreude der Ruby-Community mehr zu.
Stefan
Der Grund, warum ich Webseiten in Python programmieren will ist einfach der, weil ich mich auf eine Sprache konzentrieren will. Sämtliche Desktop Angelegenheiten sollen auch mit Python realisiert werden. Deshalb werde ich mich erst gar nicht mit RoR auseinandersetzen, selbst wenn ich dadurch an der einen oder anderen Ecke einen Vorteil hätte.
Um mein Vorhaben mal zu umreißen: ich will eine Webseite für meine Firma programmieren. Es soll vom Aufbau her ähnlich werden wie Inyoka von Ubuntuusers. Also ein Portal mit Zusammenfassungen, eine Art Blog für News und ein Online Shop. Blog und Shop sollen in Subdomains unterkommen. Als zusätzliche Komponenten könnten noch ein Wiki für Dokumentationen und eine Bauteildatenbank für Mikrocontroller dazukommen.
Gründe für eine Eigenentwicklung sind unterschiedlich. Zum einen soll alles aus einem Guss sein und zusammenspielen. Zum zweiten will ich durchgängig eine Wiki Syntax für alle Bereiche. Zum dritten habe ich bisher noch keinen Online Shop gefunden, der meine Anforderungen erfüllt oder sich mit überschaubarem Aufwand anpassen lässt. Ich habe mir z.B. den LFS angeschaut. Dort habe ich aber das Problem, dass er weder mehrsprachige Produktbeschreibungen noch Staffelpreise beherrscht.
Für mich stellt sich jetzt die Frage nach dem geeigneten Werkzeug. Nimmt man da ein "Batterys included" Kit wie TG2, Django oder vielleicht sogar Zope oder baut man sich das aus Werkzeug/Pylons, SQLAlchemy, Jinja usw zusammen. Mit Django dürften sich die ersten Erfolge schneller einstellen, aber ich weiß nicht, ob auf lange Sicht die Einzelkomponenten nicht sinnvoller wären. Ich meine auch mich erinnern zu können, dass die Programmierer bei Ubuntuusers mit Django angefangen haben und das irgendwann verworfen und mit Werkzeug, Jinja und SQLAlchemy weitergemacht haben.
Ich bin noch etwas unentschlossen und schwanke zwischen Django und Werkzeug/SQLAlchemy/Jinja. Wirklich größter Vorteil von Django ist das automatisch generierte Admin Interface. Aber da ich die meisten Daten nicht über das Web sondern remote über XML-RPC oder SOAP administrieren möchte fällt das weniger in's Gewicht.
Ach ja, SSL für die Administration und für den Bestellvorgang im Shop ist natürlich auch wichtig.
Was würdet ihr mir raten?
Um mein Vorhaben mal zu umreißen: ich will eine Webseite für meine Firma programmieren. Es soll vom Aufbau her ähnlich werden wie Inyoka von Ubuntuusers. Also ein Portal mit Zusammenfassungen, eine Art Blog für News und ein Online Shop. Blog und Shop sollen in Subdomains unterkommen. Als zusätzliche Komponenten könnten noch ein Wiki für Dokumentationen und eine Bauteildatenbank für Mikrocontroller dazukommen.
Gründe für eine Eigenentwicklung sind unterschiedlich. Zum einen soll alles aus einem Guss sein und zusammenspielen. Zum zweiten will ich durchgängig eine Wiki Syntax für alle Bereiche. Zum dritten habe ich bisher noch keinen Online Shop gefunden, der meine Anforderungen erfüllt oder sich mit überschaubarem Aufwand anpassen lässt. Ich habe mir z.B. den LFS angeschaut. Dort habe ich aber das Problem, dass er weder mehrsprachige Produktbeschreibungen noch Staffelpreise beherrscht.
Für mich stellt sich jetzt die Frage nach dem geeigneten Werkzeug. Nimmt man da ein "Batterys included" Kit wie TG2, Django oder vielleicht sogar Zope oder baut man sich das aus Werkzeug/Pylons, SQLAlchemy, Jinja usw zusammen. Mit Django dürften sich die ersten Erfolge schneller einstellen, aber ich weiß nicht, ob auf lange Sicht die Einzelkomponenten nicht sinnvoller wären. Ich meine auch mich erinnern zu können, dass die Programmierer bei Ubuntuusers mit Django angefangen haben und das irgendwann verworfen und mit Werkzeug, Jinja und SQLAlchemy weitergemacht haben.
Ich bin noch etwas unentschlossen und schwanke zwischen Django und Werkzeug/SQLAlchemy/Jinja. Wirklich größter Vorteil von Django ist das automatisch generierte Admin Interface. Aber da ich die meisten Daten nicht über das Web sondern remote über XML-RPC oder SOAP administrieren möchte fällt das weniger in's Gewicht.
Ach ja, SSL für die Administration und für den Bestellvorgang im Shop ist natürlich auch wichtig.
Was würdet ihr mir raten?
-
gerold
- Python-Forum Veteran
- Beiträge: 5555
- Registriert: Samstag 28. Februar 2004, 22:04
- Wohnort: Oberhofen im Inntal (Tirol)
- Kontaktdaten:
Hallo burli!burli hat geschrieben:und ein Online Shop
Hinter diesem Shopsystem, speziell für Skischulen, stecken mehrere Monate Arbeit.
Hier drei Beispiele:
- https://venet.skischoolshop.com/
- https://optimal.skischoolshop.com/
- https://mariaalm.skischoolshop.com/
Die verwendete Technik steht ganz unten auf den Seiten.
mfg
Gerold
PS: Der Shop wird laufend weiterentwickelt und verbessert.
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.
Burli, mein Tipp ist: Statt für das Ungewisse zu planen (was wenig Zweck hat) und das Unbekannte zu fürchten würde ich vorschlagen, lieber in dem Wissen ruhend, jedes Problem schon zur entsprechenden Zeit lösend zu können mit der einfachsten Lösung beginnen. Letztlich wirst du mit jedem Lösungsansatz zum Ziel kommen - nur mag es unterschiedlich lange dauern. Da du jetzt aber eh keine Möglichkeit hast, das abzuschätzen, ist es vergleichsweise müßig, die beste Lösung zu finden. Vertraue einfach auf das Urteil der meisten anderen (und nimm Django) oder höre auf deinen Bauch und spare dir, diese Entscheidung extra noch zu rationalisieren. Getroffen wird sie eh im Bauch - egal was dir dein Verstand da auch immer einreden will :)
Konkret für Django sehe ich keine Schwierigkeit die beschriebene Site zu bauen, wüsste allerdings nicht (da noch nie gemacht) wie man ein nicht-triviales Shop-System (insbesondere wenn es Payment-Anbindung braucht) aufbaut. Wenn's da aber auch nix passendes für TurboGears oder Zope gibt, kannst du's auch in Django bauen. Selbst wenn du jetzt sagst, du brauchst eigentlich kein Admin UI - gerade für den Anfang ist sowas recht praktisch.
Meine Alternative zu Django (müsste ich so ein Projekt umsetzen) wäre eine Kombination aus einem URL-Mapper a la Bottle oder Sinatra, einem einfachen Template-System a la Mako (wenn es okay ist, dass man da direkt Programmcode benutzen darf) zusammen mit JQuery und Less oder Sass (um das CSS ein bisschen einfacher zu machen) und MongoDB. Ein generisches Admin UI für die DB würde ich hoffen, im Rahmen des Projekts selbst bauen zu können und das benutzt oder erschafft dann auch einen passenden Formbuilder. Nachteil einer solchen Lösung wäre, dass man damit alleine dasteht. Das gilt es gegen eine beliebte Lösung abzuwägen. Würde ich mir damit gleichzeitig einen Namen durch Blogbeiträge machen wollen, wäre die exotische Lösung besser. Ich würde dann aber wohl auch aus strategischen Überlegungen Ruby wählen.
Stefan
Konkret für Django sehe ich keine Schwierigkeit die beschriebene Site zu bauen, wüsste allerdings nicht (da noch nie gemacht) wie man ein nicht-triviales Shop-System (insbesondere wenn es Payment-Anbindung braucht) aufbaut. Wenn's da aber auch nix passendes für TurboGears oder Zope gibt, kannst du's auch in Django bauen. Selbst wenn du jetzt sagst, du brauchst eigentlich kein Admin UI - gerade für den Anfang ist sowas recht praktisch.
Meine Alternative zu Django (müsste ich so ein Projekt umsetzen) wäre eine Kombination aus einem URL-Mapper a la Bottle oder Sinatra, einem einfachen Template-System a la Mako (wenn es okay ist, dass man da direkt Programmcode benutzen darf) zusammen mit JQuery und Less oder Sass (um das CSS ein bisschen einfacher zu machen) und MongoDB. Ein generisches Admin UI für die DB würde ich hoffen, im Rahmen des Projekts selbst bauen zu können und das benutzt oder erschafft dann auch einen passenden Formbuilder. Nachteil einer solchen Lösung wäre, dass man damit alleine dasteht. Das gilt es gegen eine beliebte Lösung abzuwägen. Würde ich mir damit gleichzeitig einen Namen durch Blogbeiträge machen wollen, wäre die exotische Lösung besser. Ich würde dann aber wohl auch aus strategischen Überlegungen Ruby wählen.
Stefan
Ich hab mich jetzt mehr oder weniger auf Django festgelegt. Nachdem es so viele nutzen wird es wohl schon irgendwie seinen Dienst tun. Ausschlaggebend ist vor allem das automatische Admin Interface. Da ich das meiste sowieso Remote via XML-RPC oder SOAP administrieren möchte ist das Admin Interface zwar nützlich und sollte vorhanden sein, muss aber nicht ausgefeilt sein. Ich denke, das wird einiges an Arbeit ersparen