django model für ein blog...

[jens]

Hab heute angefangen ein Blog plugin für PyLucid zu schreiben.

Ich wolle mal nachfragen, was ihr von dem bisherigen Datenbank model haltet:
http://trac.pylucid.net/browser/trunk/p ... y?rev=1686

Hab ich irgendwas vergessen?

Da wir schon mal dabei sind: Ich frage mich wie ich so eine nette Tag Cloud aufbauen sollte. Sollte man in der Datenbank lieber die Anzahl der Verwendungen eines Tags mit eintragen, quasi als Cache?

[apollo13]

Es gibt ja erst sys.maxint vorhandene blogs für Django...

[jens]

Also ich hätte jetzt ehr konstruktive Kritik erwartet

[Leonidas]

Also ich hätte jetzt ehr konstruktive Kritik erwartet

Das ist doch konstruktive Kritik, je nachdem wie du sie auslegen willst: 1) schreib nicht dein eigenes System sondern adaptier ein bereits vorhandenes oder 2) schau wie andere es machen.

[sma]

Das erste, was mir auffällt ist die Vermischung von Model und Form. Zwar muss man beides ändern, wenn man das Datenmodell anpasst, doch ich würde es trotzdem trennen, weil Forms für mich Teil des "View"-Teils sind, nicht des "Model"-Teils einer Anwendung.

Für Kommentare würde ich nicht speichern, wann sie aktualisiert wurden - ja dieses gar nicht zulassen. Auch hätte ich meine Zweifel, dass da jemand ernsthaft seine Email-Adresse eingibt. Entweder man hat User - und dann machen die ganze Angaben Sinn - oder aber es ist IMHO einfach ein Text zu einem bestimmten Datum. Es wäre vielleicht ganz nett, wenn der Autor noch z.B. eine Stunde lang seinen Kommentar anpassen kann, etwa falls er ihn (unerwarteterweise ;) nach dem Schreiben nochmals liest und noch einen Schreib- oder Formatierfehler sieht. Dazu bräuchte man dann wohl noch einen Nonce.

Für Tags fand ich django-tagging praktisch. Falls du es selbst machen willst, lohnt dort aber abgucken. Taganzahlen würde ich wohl erst dann cachen, wenn es messbar langsamer ist, die Datenbank selbst zählen zu lassen.

Beim BlogEntry würde ich hingegen mich zu einer Optimierung hinreißen lassen und neben dem Rohtext auch das HTML-Fragment speichern, damit die Darstellung schneller geht. Ist aber vielleicht ein zu unterdrückender Implus. Ansonsten fällt mir zu dem vorliegenden Modell nichts weiter ein.

Was ich ganz interessant bei Wordpress finde ist, dass sie Blog-Postings auch als statische Seiten einsetzen können. Dazu wird glaube ich dann noch ein URL-Segment abgelegt. Eine Versionierung wie in der aktuellen WP-Version wäre auch IMHO praktisch. Gerade wenn man mit mehreren Leuten an einem Blog-Eintrag arbeiten will. Das alles geht dann aber schon etwas mehr in Richtung CMS.

Stefan

[jens]

Vielen Dank sma. Endlich mal jemand der was produktives von sich gibt

Das erste, was mir auffällt ist die Vermischung von Model und Form. Zwar muss man beides ändern, wenn man das Datenmodell anpasst, doch ich würde es trotzdem trennen, weil Forms für mich Teil des "View"-Teils sind, nicht des "Model"-Teils einer Anwendung.

Weiß jetzt nicht genau was du meinst. Stört sich das alle Klassen in einer Datei sind? Das werde ich allerdings auch ändern, weil blog.py jetzt doch arg lang ist.

Aber das ist ein gutes Thema. In django ist Model und Form nicht so stark getrennt, aber irgendwie schon ein wenig. Also z.B. Ich kann in einem Model sagen Feld XY darf nur X Zeichen lang sein. Ich kann auch sagen, ob dieses Feld leer sein darf. Ich kann aber im Model nicht sagen, es muß mindestens X Zeichen lang sein. Das würde auch nicht in der SQL Datenbank abgelegt werden.
Allerdings kann man z.B. einen help_text auch im Model angeben. Das ist nett, wenn man z.B. im django admin panel sich die Sachen anschaut.
Erstelle ich jetzt eine Form für diese Klasse. Kann ich entweder von Null anfangen oder eine ModelForm nehmen (IMHO die Nachfolge von form_from_model und form_from_instance).
Dumm ist allerdings, das ich in der Form sagen will, Das Feld XY soll mindestens X Zeichen lang sein. Also muß ich das Feld in der ModelForm neu definieren. Dabei muß ich dann z.B. den help_text neu schreiben und auch max_length neu festlegen.

Irgendwie doof, oder?

IMHO wäre es nett wenn also model und form noch näher zusammen liegen würden.

Für Kommentare würde ich nicht speichern, wann sie aktualisiert wurden - ja dieses gar nicht zulassen.

Mehr Information als man brauchst zu speichern ist nicht immer schlecht
Der Admin kann jetzt schon jeden Kommentar editieren. Der User kann es noch nicht, aber vielleicht kommt das nicht. Auf jeden Fall sollte es auch angezeigt werden.

Es wäre vielleicht ganz nett, wenn der Autor noch z.B. eine Stunde lang seinen Kommentar anpassen kann, etwa falls er ihn (unerwarteterweise nach dem Schreiben nochmals liest und noch einen Schreib- oder Formatierfehler sieht. Dazu bräuchte man dann wohl noch einen Nonce.

Ja, mal sehen. Das wäre noch ein nice to have.
Eine Preview ist aber vielleicht noch besser

Auch hätte ich meine Zweifel, dass da jemand ernsthaft seine Email-Adresse eingibt. Entweder man hat User - und dann machen die ganze Angaben Sinn - oder aber es ist IMHO einfach ein Text zu einem bestimmten Datum.

Also das jemand eine EMail angibt ist IMHO nicht das Problem. Weiß auch nicht in wie fern das vom deutschem Recht sogar verlangt wird (Ist mir jetzt auch egal). Allerdings ist es für direkte Rückfragen nett, außerdem kann man daran evtl. schon erkennen ob es Spam ist.

Für Tags fand ich django-tagging praktisch. Falls du es selbst machen willst, lohnt dort aber abgucken.

Das kam jetzt zu spät. Tagging gibt's jetzt schon. Ist ja ein einfaches many-to-many. Allerdings hatte ich mit dem Eintragen ein wenig Probleme. Aber es funktioniert.
Was ich mir aber mal abschauen kann, ist wie man diese Cloud Geschichte berechnen kann...

Taganzahlen würde ich wohl erst dann cachen, wenn es messbar langsamer ist, die Datenbank selbst zählen zu lassen.
Beim BlogEntry würde ich hingegen mich zu einer Optimierung hinreißen lassen und neben dem Rohtext auch das HTML-Fragment speichern, damit die Darstellung schneller geht. Ist aber vielleicht ein zu unterdrückender Implus. Ansonsten fällt mir zu dem vorliegenden Modell nichts weiter ein.

Uber das Caching muß ich mir noch Gedanken machen. Aber ich denke ich setzte den Cache Hebel eh viel früher an. Somit ist IMHO ein HTML Cache per DB nicht unbedingt erforderlich.

Was ich ganz interessant bei Wordpress finde ist, dass sie Blog-Postings auch als statische Seiten einsetzen können. Dazu wird glaube ich dann noch ein URL-Segment abgelegt.

Das habe ich jetzt nicht ganz verstanden. Man kann eine HTML Seite erzeugen und die dann als Blog Eintrag nutzten?

Eine Versionierung wie in der aktuellen WP-Version wäre auch IMHO praktisch. Gerade wenn man mit mehreren Leuten an einem Blog-Eintrag arbeiten will. Das alles geht dann aber schon etwas mehr in Richtung CMS.

Naja, vielleicht tut's später mal ein einfaches Archiv, welches vor einer Änderung die alte Version des Eintrags speichert. Finde ich aber jetzt nicht so wirklich wichtig.

btw. Das wichtigste für mich ist erstmal, das RSS/Atom Feeds generiert werden. Da Arbeite ich gerade dran...

[Leonidas]

Was ich mich ja frage, ist ob die Namen der Funktionen und Klassen zufällig sind? Du hast ja da viele Stile zusammengemischt (Lowercase-Klassen? CamelCase Methoden?). ``mod_comment`` ist auch irgendwie kein sonderlich toller Name.

Davon abgesehen hast du jetzt auch erstmal ein wenig Arbeit, die ganzen Admin-Klassen auf newforms-admin zu portieren...

[lunar]

Beim BlogEntry würde ich hingegen mich zu einer Optimierung hinreißen lassen und neben dem Rohtext auch das HTML-Fragment speichern, damit die Darstellung schneller geht. Ist aber vielleicht ein zu unterdrückender Implus.

Datenbanken sind für Daten und sollten nicht als Cache missbraucht werden, zumal sich die Datenbank selbst manchmal als Flaschenhals erweist. Unter Last dürften Datenbankzugriff und das Rendern des kompletten Seiten-Templates so "teuer" sein, dass das zusätzliche Rendern des Blogeintrags nicht ins Gewicht fällt. Da wiegt der Aufwand der Optimierung – immerhin muss man Rohdaten und HTML-Fragment auch bei nachträglichen Änderungen synchron halten – und der Verlust der logischen Trennung (das Rendern des Blogeintrags in HTML gehört imho auch zum "View" und nicht zum "Model") den Performancegewinn nicht auf.

Wenn schon Caching, dann richtig, nämlich in dem man fertig gerenderte HTML-Seiten im RAM vorhält. Django bietet afaik ja eh schon eine Anbindung an memcache.

[sma]

Was ich ganz interessant bei Wordpress finde ist, dass sie Blog-Postings auch als statische Seiten einsetzen können. Dazu wird glaube ich dann noch ein URL-Segment abgelegt.

Das habe ich jetzt nicht ganz verstanden. Man kann eine HTML Seite erzeugen und die dann als Blog Eintrag nutzten?

Anders herum. Man kann dort genau wie man Blog-Artikel schreibt, auch statische Seiten schreiben und so Wordpress wie ein kleines CMS nutzen. Das ist nicht nur praktisch für die typische "About us"-Seite, sondern auch für längerfristige Artikel, Download-Seiten usw.

Eine Versionierung wie in der aktuellen WP-Version wäre auch IMHO praktisch.

Naja, vielleicht tut's später mal ein einfaches Archiv, welches vor einer Änderung die alte Version des Eintrags speichert. Finde ich aber jetzt nicht so wirklich wichtig.

Ich denke, Versionierung muss man von Anfang an integrieren. Andererseits: Bei WP kam es auch erst jetzt hinzu. Müsste mal schauen, wie das realisiert ist. Ob die einfach parallel eine zweite Tabelle für die Versionen haben oder wurde die BlogEntry-Tabelle um eine Versionsspalte ergänzt? Das macht aber alle Abfragen aufwendiger, weil man hier jetzt filtern muss.

Das wichtigste für mich ist erstmal, das RSS/Atom Feeds generiert werden. Da Arbeite ich gerade dran...

Das kann Django doch quasi automatisch.

Stefan