Ja, ich hab es einfach nicht hinbekommenveers hat geschrieben:Gibts einen Grund wieso du nicht einen eigenen Template Tag schreibst oder den von Greenpeace portierst?
Siehst du: Du brauchst SQLAlchemy gar nicht. Warum solltest du es dann einsetzen. Das ist in dem Fall sinnbefreit. Was ich gebraucht hätte, waren sortierte Felder im Django-ORM, was ich dann durch ein zusäzliches ``position``-Feld und einiges an Meta-Magie gelöst habe.jens hat geschrieben:Allerdings finde ich, gibt es kaum Einschränkungen mit django
Der Mutually-Referential-Bug. Der ist inzwischen zwar geöst, aber das hat auch schon ziemlich lange gedauert.jens hat geschrieben:Welche Bugs hast du denn im ORM gefunden? Sind die Fehler bekannt?
Die Argumente an die Filter sind sinnlos gelöst, das i18n-System ist fest an ``gettext`` verdrahtet (habe mir gestern angeschaut wie es in Jinja ist - wesentlich besser), es ist nicht möglich mehrere Variablen zusammenzufassen und sie dann zu ``joinen`` (braucht man, wenn man mehrere Felder aus dem Model mit Kommas zwischendrin anzeigen will), es ist nicht möglich diese Argumente davor noch zu übersetzen, etc. Klar, das meiste lässt sich mit eigenen Tags machen, aber die muss man erstmal schrieben.jens hat geschrieben:Was genau findest du an der Template Engine beschränkt?
Zu dem Thema gehts hier weiter: http://www.python-forum.de/topic-10824.htmlLeonidas hat geschrieben:Was ich gebraucht hätte, waren sortierte Felder im Django-ORM
Der springende Punkt ist für mich einfach der, dass ein WSGI-basiertes Framework eine feste Schnittstelle besitzt. Dadurch kann sowohl der einzige Anwender als auch eine Masse von Nutzern es auf beliebigem Wege deployen. Sei es Apache, Lighty oder Standalone, auch nur zum Testen oder Weiterentwickeln. Und spätestens wenn ein Tausch des Webservers, ein Umzug auf einen anderen Server, das Nutzen eines zweiten, anders ausgestatteten Servers ansteht, ein essentielles Paket nicht mehr weiterentwickelt wird und/oder gravierende Sicherheitslöcher darin gefunden werden, was einen solchen Wechsel unausweichlich macht, wirst du dir in den Arsch beißen, wenn du dich mit einer Anwendung oder einem Framework fest bspw. Apache+mod_python verschrieben hast. Mit WSGI bleibst du langfristig flexibel.N317V hat geschrieben:Nun es wurde nach einem Framework gefragt, Karigell vorgeschlagen und dann dagegen argumentiert mit "Nicht WSGI-kompatibel". Das kann natürlich ein Aspekt in der Entscheidung für oder gegen ein bestimmtes Framework sein, aber ich hab manchmal den Eindruck, als sei das das allerallerwichtigste überhaupt, während es mir, offen gesagt, völlig wurscht ist. Wie meine Applikation mit der Umwelt kommuniziert, das Problem löse ich pro Installation ein einziges mal, während ich mich mit fast allen anderen Aspekten eines Frameworks doch viel häufiger rumschlagen muss.
Na klar, das ist ein super Vorteil. Ich kann es aber nicht als alleiniges K.O.-Kriterium gelten lassen, einfach weil ein Framework aus so viel mehr Komponenten und Aspekten besteht. Mich nervt ehrlich gesagt auch dieses WSGI-Kreuzrittertum. Wenn Ihr wollt, dass WSGI weiter verbreitet wird, dann schreibt bitte mehr verständliche Artikel und Tutorials dazu, aber bitte, bitte verschont mich mit sowas wie dem animierten GIF mit den Blitzen. Die Zeit die es kostet sowas zu erstellen, kann man sicherlich sinnvoller nutzen.Y0Gi hat geschrieben:Der springende Punkt ist für mich einfach der, dass ein WSGI-basiertes Framework eine feste Schnittstelle besitzt. [...] Ist das nicht ein gravierender Vorteil?
Das ist es doch gerade: Jedes Python-Webframework sollte auf WSGI aufsetzen. Dann hat man über WSGI die freie Wahl des Deployment und über das Framework wie Wahl der Funktionalität, die man sich damit dazuholt. Es sollten also *alle* Frameworks WSGI können, damit man die Wahl anhand der eigentlichen Framework-Fähigkeiten hat.N317V hat geschrieben:Na klar, das ist ein super Vorteil. Ich kann es aber nicht als alleiniges K.O.-Kriterium gelten lassen, einfach weil ein Framework aus so viel mehr Komponenten und Aspekten besteht.
