Photomatt (der von Wordpress) hat mit Akismet einen zentralen Anti-Spam-Dienst aufgebaut, den man per Plugin mit Wordpress benutzen kann. Zusätzlich gibts auch eine API, mit der man andere Dienste anbinden kann. Grundsätzlich eine gute Idee - auch wenn ich generell eine Abneigung gegen zentrale Dienste habe, ausser ich selber betreibe diese zentralen Dienste.
Was mir aber wirklich sauer aufstößt, ist dieser kleine Ausschnitt aus der FAQ:
Well without giving too much of the secret sauce away, we can safely say that it would be pretty difficult to poison Akismet.
Also zentraler Dienst - ok. Mag ich zwar nicht, aber macht durchaus für andere Sinn, die nicht selber sowas betreiben können oder wollen. Aber "secret sauce" - ich soll also meine Kommentare mit den persönlichen Daten meiner Kommentatoren an ein fremdes System schieben, bei dem ich nicht mal die Software sehen kann, die dahinter läuft? Sorry, nein Danke.
Wie können Sie feststellen, ob ein Framework zu Ihrer Denkweise passt? Es ist nicht so, dass Sie einfach in den Spiegel schauen könnten, um zu sehen, ob es Ihnen gefällt. Sie benötigen andere Wege, um das zu entscheiden. Eine Möglichkeit, dies zu entscheiden, ist die Produktivität - wie schnell Sie Ihr Projekt zum Laufen bringen.
Aber erzählt Ihnen das wirklich die ganze Geschichte? Was, wenn das Projekt etwas völlig anderes gewesen wäre? Haben Sie einfach den Sweet Spot des Frameworks getroffen? Hatten Sie einfach nur Glück?
Eine Möglichkeit, zu entscheiden, ob ein bestimmtes Framework, eine Sprache oder ein Werkzeug zu meiner Arbeitsweise passt, besteht darin, die grundlegenden Abstraktionen zu betrachten, die mir dieses Werkzeug bietet. Und zu prüfen, wie ich sie verwenden kann und wie natürlich sie zu meinem Denken passen - stoße ich auf Probleme, weiß ich nicht sofort, welche Abstraktion ich verwenden soll, welches Werkzeug ich ziehen soll? Oder fallen die Dinge einfach an ihren Platz?
Ich habe relativ früh entdeckt, dass ich in der Programmierung etwas ungewöhnlich bin, weil ich nicht meine eigenen Abstraktionen baue und versuche, sie in das zu übersetzen, was die Sprache oder das Framework mir gibt, sondern dass ich beginne, direkt in den Abstraktionen und Syntaxen zu denken, die mir gegeben werden - aber nur wenn sie zu meiner Art passen.
Das ist für mich also das ultimative Maß dafür, ob ein Framework wirklich in mein Denken passt: von Zeit zu Zeit zu prüfen, ob ich Übersetzungen versuche oder ob die Dinge einfach fließen. "In den Flow zu kommen" ist für mich heutzutage das Wichtigste.
Wie schneidet Django also ab? quite nicely. Es gibt mir wirklich, was ich in den meisten Fällen brauche, es gibt nur sehr wenige Bereiche, in denen "der Flow" unterbrochen wird, in denen ich um Probleme herumdenken muss, anfangen muss, Übersetzungen zu machen. Ein Bereich ist das spezielle Verhalten von Eingabefeldern - dies wird derzeit in Django mit parametrisierten Instanzen von vordefinierten Feldklassen durchgeführt. Es gibt keine wirklich schöne Möglichkeit, Subklassen zu erstellen, man endet damit, Code aus anderen Teilen der Django-Quelldatei zu kopieren - definitiv "den Flow" brechend.
Aber die meisten anderen Teile fallen einfach an ihren Platz: Middleware für die globale Verwaltung des Request-Response-Bereichs. Template-Loader für - nun ja - Template-Loading (ja, es ist keine große Sache - aber in der Lage zu sein, Ihren eigenen Template-Loader zu schreiben, ist wirklich hilfreich). Die urlpatterns - hey, das ist wirklich eine coole Idee, weil Sie aufgrund der absolut lockeren Kopplung nicht einmal versuchen, Ihre URLs nach Ihrer Code-Struktur zu modellieren, sondern dazu neigen, sie zu entwerfen. Und so sollte es sein.
Models sind leistungsfähig genug, um die modellbezogene Funktionalität wirklich dorthin zu verlagern (obwohl das Class MODULE-Zeug es noch schöner machen wird, besonders das etwas hässliche module_globals-Ding). Es wäre cool, wenn Model-Klassen Mixin-Klassen unterstützen würden, so dass abstrakte Apps Dinge bereitstellen könnten, die einfach von den Benutzern referenziert werden, um Funktionalität hinzuzufügen. Aber Sie können viele dieser Probleme mit generierten Klassen lösen - dank Python-Introspektion (obwohl Sie ein wenig über die Django-Modellmagie wissen müssen).
Die meisten komplexen Dinge tendieren dazu, in Template-Tags und generische Ansichten zu gehen - mein CMS-Projekt hat derzeit nur 3 Ansichtsfunktionen seiner eigenen, der Rest ist in generische Ansichten abstrahiert (für die Suche und das Tagging). Template-Tags könnten etwas einfacher zu schreiben sein, insbesondere der Parser ist zu primitiv - eine Bibliothek von Hilfsfunktionen zum einfachen Zerlegen der Tag-Zeichenkette wäre gut (hey, vielleicht schreibe ich eine, die Grundlagen sind bereits in meinem SVN-Repository).
Template-Filter sind ein bisschen ein hässliches Entlein - sie sehen den Anforderungszusammenhang nicht, so dass sie nicht viel mehr tun können, als das eingehende Objekt und einige konstante Parameter zu übernehmen. Ich denke, sie sollten den Kontext übergeben bekommen, so dass sie, wenn nötig, ein bisschen schlauer sein könnten (wie z.B. das Auflösen eines Parameters gegen den Kontext durch Filter ermöglichen).
Generische Ansichten sind auch ganz schön - auch wenn ich die vordefinierten nicht so oft verwende. Der Hauptgrund dafür ist, dass ich oft damit ende, die generischen Ansichten in einigen Code zu wickeln, der ihr Verhalten modifiziert - und dann ist es oft einfacher, einfach meine eigenen zu erstellen. Aber sie sind großartig für den ersten Einstieg in Bereiche, hängen Sie sie einfach in Ihr Projekt ein und die Funktionalität ist verfügbar. Sie können sie immer durch Ihre eigenen Ansichtsfunktionen austauschen, wenn Sie feststellen, dass Sie sie benötigen.
Und der Admin, das eine Ding, das Django aus der Masse herausstechen lässt? In meinen ersten Spielprojekten habe ich ihn geliebt, in späteren habe ich ihn nicht verwendet (die Galerie braucht ihn nicht), aber mit dem CMS-Projekt habe ich das erste Projekt gemacht, das ihn wirklich stark nutzt. Und ich muss sagen, ich mag ihn. Er sollte etwas flexibler werden (der new_admin-Zweig könnte dabei helfen, da er mehr Dinge in Templates verschiebt, so dass sie überschrieben werden können), aber insgesamt ist er wirklich cool und nützlich.
Zwei Dinge sind jedoch definitiv für den Admin erforderlich: vollständige Transaktionsunterstützung, die an die Anforderung-Antwort gebunden ist (Ticket #9 im Django Trac), weil das Ändern von Dingen und das Ende mit inkonsistenten Tabellen kein Spaß ist. Wie z.B. eine Ausnahme zu erhalten, weil etwas in repr gebrochen ist, so dass der Log-Eintrag nicht geschrieben wird, aber das Objekt wird geschrieben. Natürlich bemerken Sie es nicht, gehen zurück, senden erneut und enden mit zwei Objekten und immer noch keiner Log-Nachricht ...
Das andere, was benötigt wird: grundlegende Haken für objektbasierte Authentifizierung. Kein vollständiges ACL oder so etwas, nur einige wirklich einfache Haken vom Admin zum Modell, die der Benutzer definieren kann, um dem Admin mitzuteilen, ob ein bestimmtes Objekt bearbeitbar sein sollte oder nur schreibgeschützt angezeigt werden sollte. Das Hauptproblem mit der aktuellen Lösung ist, dass sie nur vollständige Tabellen behandelt - Sie können dem Admin nicht einmal mitteilen, dass ein bestimmter Benutzer nur an der aktuellen Site arbeiten kann und keine Objekte anderer Sites ändern kann (mein CMS-Projekt macht starken Gebrauch von der Multi-Site-Fähigkeit in Django - ein Admin-Server sollte mehrere Sites in einer Admin-Oberfläche verwalten).
Aber alles in allem ist das Erstellen von Web-Apps mit Django wirklich Spaß. Es ist nicht nur produktiv für mich, es fühlt sich natürlich an, Dinge auf die Django-Art zu tun. Also ja, Django passt zu meinem Denkstil. Scheint genau ins Schwarze getroffen zu haben.
Django enthält bereits einen Markdown-Filter (in contrib.markup), dennoch habe ich meine eigene Markdown für Django Mini-Anwendung erstellt. Die Hauptvorteile sind die Verknüpfung mit Django-Modellen (durch Verwendung generischer Modellabfragen und get absolute url), eine generische Dokumentationsansicht, die das Umschalten der Sprache handelt, und eine schöne Makro-Einrichtung für Markdown. Makros sind eine nützliche Möglichkeit, Markdown zu erweitern, indem Django-Vorlagenschnipsel geschrieben werden, die immer dann aufgerufen werden, wenn der Benutzer das Makro in seiner Markdown-Quelle aufruft.
Es war früher Teil des CMS-Projekts, aber ich denke, es ist nützlich in sich und so viel besser in das Stuff-Pseudo-Projekt einzubauen.
