django model für ein blog...

Sockets, TCP/IP, (XML-)RPC und ähnliche Themen gehören in dieses Forum
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

django model für ein blog...

Beitragvon jens » Dienstag 15. Juli 2008, 18:48

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?

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
apollo13
User
Beiträge: 827
Registriert: Samstag 5. Februar 2005, 17:53

Beitragvon apollo13 » Dienstag 15. Juli 2008, 19:44

Es gibt ja erst sys.maxint vorhandene blogs für Django... :roll:
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Mittwoch 16. Juli 2008, 17:19

Also ich hätte jetzt ehr konstruktive Kritik erwartet :roll:

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Mittwoch 16. Juli 2008, 23:44

jens hat geschrieben:Also ich hätte jetzt ehr konstruktive Kritik erwartet :roll:

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.
My god, it's full of CARs! | Leonidasvoice vs Modvoice
sma
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Beitragvon sma » Samstag 19. Juli 2008, 08:45

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
Benutzeravatar
jens
Moderator
Beiträge: 8458
Registriert: Dienstag 10. August 2004, 09:40
Wohnort: duisburg
Kontaktdaten:

Beitragvon jens » Samstag 19. Juli 2008, 19:58

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

sma hat geschrieben: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.

sma hat geschrieben: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.

sma hat geschrieben: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 ;)

sma hat geschrieben: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.

sma hat geschrieben: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...

sma hat geschrieben: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.

sma hat geschrieben: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?

sma hat geschrieben: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...

CMS in Python: http://www.pylucid.org
GitHub | Open HUB | Xing | Linked in
Bitcoins to: 1JEgSQepxGjdprNedC9tXQWLpS424AL8cd
Benutzeravatar
Leonidas
Administrator
Beiträge: 16023
Registriert: Freitag 20. Juni 2003, 16:30
Kontaktdaten:

Beitragvon Leonidas » Samstag 19. Juli 2008, 21:33

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...
My god, it's full of CARs! | Leonidasvoice vs Modvoice
lunar

Beitragvon lunar » Sonntag 20. Juli 2008, 11:12

sma hat geschrieben: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
User
Beiträge: 3018
Registriert: Montag 19. November 2007, 19:57
Wohnort: Kiel

Beitragvon sma » Sonntag 20. Juli 2008, 11:25

jens hat geschrieben:
sma hat geschrieben: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.

jens hat geschrieben:
sma hat geschrieben: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.

jens hat geschrieben: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

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder