Welche Features sollte ein Webblog haben?

[Siechfred]

Привет.

Nach reiflicher Überlegung und im Ergebnis einer etwas länger zurück liegenden Diskussion im Selfchat bin ich zu dem Entschluss gekommen, mir mein eigenes kleines Webblog zu schreiben. Da ich mich momentan noch in der konzeptionellen Phase befinde, bitte ich euch um eure Meinung, was so alles zu einem Webblog gehört. Bisherige Überlegungen:

• Datenhaltung mit Hilfe einer mySQL-Datenbank
• Programmiersprache Perl, die Ausgabe mit HTML und etwas Javascript
• sprechende URLs mit Hilfe von mod_rewrite
• Übersicht der Einträge nach Jahr/Monat/Thema
• Neue Einträge sind nur durch mich möglich
• Kommentieren kann jeder, das Löschen unerwünschter Kommentare behalte ich mir vor
• Möglichkeit des Anlegens von Nutzerprofilen
• maßvoller Einsatz von BBCode (URL, Bilder, Textformatierung)

Das wären so meine momentanen Ideen. Fällt euch noch was ein/auf? Sollte ich alles in ein Script packen oder besser mehrere Scripts verwenden oder evtl. eigene Module schreiben? Danke für jede Meinung.

Дружба!
Siechfred

[Bio]

Sup!

Привет.

Ja, klar, DU MICH AUCH!

• Datenhaltung mit Hilfe einer mySQL-Datenbank

Echte Männer nehmen aber PostGreSQL.

• Programmiersprache Perl, die Ausgabe mit HTML und etwas Javascript
• sprechende URLs mit Hilfe von mod_rewrite
• Übersicht der Einträge nach Jahr/Monat/Thema
• Neue Einträge sind nur durch mich möglich
• Kommentieren kann jeder, das Löschen unerwünschter Kommentare behalte ich mir vor
• Möglichkeit des Anlegens von Nutzerprofilen

Okay...

• maßvoller Einsatz von BBCode (URL, Bilder, Textformatierung)

BBCode... so peinlicher Board-Quatsch? Wie tief bist Du gesunken!

Das wären so meine momentanen Ideen. Fällt euch noch was ein/auf? Sollte ich alles in ein Script packen oder besser mehrere Scripts verwenden oder evtl. eigene Module schreiben? Danke für jede Meinung.

Total wichtig ist, dass alles extrem wiederverwendbar, objektorientiert und getrennt in Datenhaltungs-, Logik- und Darstellungsschicht ist und ein Interface zu .NET, Tcl, Phyton und mindestens dreissig anderen angesagten Programmiersprachen hat.
Die Struktur der User-Daten muss in Meta-Daten in XML abgelegt sein, die User-Daten selbst natürlich auch, bzw. sollte die Datenbankabfragen basierend auf den XML-Metadaten on-the-fly erstellt werden, und das Datenbankschema sollte sich automatisch einer Veränderung der Meta-Daten anpassen.

Aber nee... ich würde versuchen, sinnvoll zu modularisieren, es aber nicht zu übertreiben, lohnt sich nicht.

Gruesse,

Bio

[Ludger]

Hi,

Total wichtig ist, dass alles extrem wiederverwendbar, objektorientiert

;-)

und getrennt in Datenhaltungs-, Logik- und Darstellungsschicht ist

Mir ist die Trennung von Logik und Datenzugriff nie gelungen. Das geht doch nicht wirklich, oder?

Gruss,
Ludger

[Bio]

Sup!

Mir ist die Trennung von Logik und Datenzugriff nie gelungen. Das geht doch nicht wirklich, oder?

Es scheint zumindest schwierig zu sein; ein paar Bekannte von mir haben sich einmal sehr schwer damit getan, und in Java den doppelten Entwicklungsaufwand für ein Programm gehabt wie "mein" Team mit einer möglicherweise nicht ganz so "elegant" programmierten Perl-Lösung.

Gruesse,

Bio

[Jörg Peschke]

Moin,

Echte Männer nehmen aber PostGreSQL.

So? Dann mach ich was falsch.

Die Struktur der User-Daten muss in Meta-Daten in XML abgelegt sein, die User-Daten selbst natürlich auch, bzw. sollte die Datenbankabfragen basierend auf den XML-Metadaten on-the-fly erstellt werden, und das Datenbankschema sollte sich automatisch einer Veränderung der Meta-Daten anpassen.

Jetzt wissen wir's es waren nicht Androiden die in Terminator die Weltherrschaft an sich gerissen haben, es waren die Blogs ;)

[Bio]

Sup!

Echte Männer nehmen aber PostGreSQL.
So? Dann mach ich was falsch.

Falls Du die Möglichkeit hättest, PostGreSQL zu nehmen (was ich annehme), dann wäre das in Betracht zu ziehen, da PostGreSQL mehr Features hat und auch von der Syntax her näher an Oracle etc. rankommt, was ja ggf. auch von Vorteil ist.

Jetzt wissen wir's es waren nicht Androiden die in Terminator die Weltherrschaft an sich gerissen haben, es waren die Blogs ;)

Ja... die mit den zuvielen Features ;-)

Gruesse,

Bio

[Jörg Peschke]

Sup!

Echte Männer nehmen aber PostGreSQL.
So? Dann mach ich was falsch.

Falls Du die Möglichkeit hättest, PostGreSQL zu nehmen (was ich annehme), dann wäre das in Betracht zu ziehen, da PostGreSQL mehr Features hat und auch von der Syntax her näher an Oracle etc. rankommt, was ja ggf. auch von Vorteil ist.

Die meisten WebServer sind halt LAMPs, keine LAPPS, deswegen MySQL :)
Aber wenn Du so davon schwärmst, probier ichs vielleicht mal auf unserem Testserverchen aus.

gruesse,
Joerg

[Bio]

Sup!

Die meisten WebServer sind halt LAMPs, keine LAPPS, deswegen MySQL :)
Aber wenn Du so davon schwärmst, probier ichs vielleicht mal auf unserem Testserverchen aus.

Ich muss zugeben, ich habe es nur einmal benutzt bei meinem "Website Engineering" Proseminar - aber damals war es mySQL wegen der Möglichkeiten (Constraints, kaskadierendes Löschen, geschachtelte Queries) weit überlegen. Wir hätten uns totprogrammiert ohne kaskadierendes Löschen.

Gruesse,

Bio

[Ludger]

Hi,

Ich muss zugeben, ich habe es nur einmal benutzt bei meinem "Website Engineering" Proseminar - aber damals war es mySQL wegen der Möglichkeiten (Constraints, kaskadierendes Löschen, geschachtelte Queries) weit überlegen. Wir hätten uns totprogrammiert ohne kaskadierendes Löschen.

ist das kaskadierende Loeschen serioes und hilfreich? (Ich habe mich davon immer ferngehalten, aber ich lerne gerne dazu.)

Gruss,
Ludger

[Bio]

Sup!

Also, wenn Du z.B. zwei Tabellen für Kunden- und Veranstaltungsnamen und deren IDs hast:

Kundenname - KId
Veranstaltungsname - VId

und eine Tabelle, die aussagt, welche Kunden zu welcher Veranstaltung kommen

KId - VId

und dann eine Veranstaltung oder ein Kunde gelöscht wird - dann löscht das Kaskadierende Löschen auch gleich den Eintrag in der KId-VId-Tabelle, und es gibt keinen Datenmüll, der manuell aufgeräumt werden müsste, weil er sonst die Datenintegrität gefährden könnte. Extrem praktisch.

Gruesse,

Bio

[Ludger]

Hi,

und dann eine Veranstaltung oder ein Kunde gelöscht wird - dann löscht das Kaskadierende Löschen auch gleich den Eintrag in der KId-VId-Tabelle, und es gibt keinen Datenmüll, der manuell aufgeräumt werden müsste, weil er sonst die Datenintegrität gefährden könnte. Extrem praktisch.

schon klar. Ich habe mich nur davor ferngehalten, weil es einen Datenzugriff neben dem eigentlichen Datenzugriff darstellt und darum sicherlich auch ein Mehr an (unverwalteter ;-) Komplexitaet. (Auch dem Einsatz von Triggern stehe ich hoechstskeptisch gegenueber.)

Wer moechte schon einen Kunden loeschen, der keinen laufenden Vertrag mehr hat?   ;-)

Gruss,
Ludger

[Bio]

Sup!

schon klar. Ich habe mich nur davor ferngehalten, weil es einen Datenzugriff neben dem eigentlichen Datenzugriff darstellt und darum sicherlich auch ein Mehr an (unverwalteter ;-) Komplexitaet. (Auch dem Einsatz von Triggern stehe ich hoechstskeptisch gegenueber.)

Da ein Datenbanksystem sowieso hochkomplex ist, ist so ein kleines kaskadierendes Löschen auch keine grosse Sache.
Ich sehe Trigger, Contraints etc. einfach als zusätzliche Sicherheitsschicht und als "assert" gegen Programmfehler.

Gruesse,

Bio

[Ludger]

Hi,

Da ein Datenbanksystem sowieso hochkomplex ist, ist so ein kleines kaskadierendes Löschen auch keine grosse Sache.

das Argument kenne ich. Warum Komplexitaet _jetzt noch_ vermeiden? Ist doch ohnehin alles schon so komplex.   ;-)

Ich sehe Trigger, Contraints etc. einfach als zusätzliche Sicherheitsschicht und als "assert" gegen Programmfehler.

Man kann in der Datenzugriffsschicht grundsaetzlich alles machen, was die Trigger in der Datenschicht so machen. Ich sehe eigentlich nur einen sinnvollen Einsatz fuer Trigger fuer Alerts (Mitarbeiter X erfahert eine Aenderung des Datenfelds 'Monatsgehalt' in der Mitarbeitertabelle => Mail an den Personalchef.).

Allerdings ist meine Meinung da recht unsicher und unbestaetigt. Es ist schon interessant den Datendesigner bestimmte Datenzugriffe (kaskadierende Deletes und Trigger) bereits in seiner Datenschicht durchfuehren zu lasssen. Mein Gegenargument ist die Komplexitaet ("Ein kaskadierendes Delete hat den Delete-Trigger x ausgloest, der wiederum den Delete-Trigger y ausgeloest hat. Nun haben wir alle Datensaetze der Tabelle z geloescht, die im Jahr 1994 angelegt wurden."   :-(   :-)

Aber wer kann solche sehr schwierigen Fragen heute noch zuverlaessig beantworten?   ;-)

Gruss,
Ludger

[Bio]

Sup!

Man kann in der Datenzugriffsschicht grundsaetzlich alles machen, was die Trigger in der Datenschicht so machen. Ich sehe eigentlich nur einen sinnvollen Einsatz fuer Trigger fuer Alerts (Mitarbeiter X erfahert eine Aenderung des Datenfelds 'Monatsgehalt' in der Mitarbeitertabelle => Mail an den Personalchef.).

Die Datenbank kann auf jeden Fall diese Beschränkungen und Kaskadierungen schnell und zuverlässig ausführen; der aktive Zugriff über SQL kostet mehr.

Allerdings ist meine Meinung da recht unsicher und unbestaetigt. Es ist schon interessant den Datendesigner bestimmte Datenzugriffe (kaskadierende Deletes und Trigger) bereits in seiner Datenschicht durchfuehren zu lasssen. Mein Gegenargument ist die Komplexitaet ("Ein kaskadierendes Delete hat den Delete-Trigger x ausgloest, der wiederum den Delete-Trigger y ausgeloest hat. Nun haben wir alle Datensaetze der Tabelle z geloescht, die im Jahr 1994 angelegt wurden."   :-(   :-)

Wenn Du Angst hast, auf dieser Ebene etwas falsch zu machen (Du hast doch sicher immer ein Backup?), wie kommst Du dann darauf, dass Deine auf höherer Ebene programmierten äquivalenten Mechanismen zuverlässiger und weniger gefährlicher sind bzw. wären?

Aber wer kann solche sehr schwierigen Fragen heute noch zuverlaessig beantworten?   ;-)

Wenn überhaupt jemand, dann natürlich ich. Und ich sage: Constraints und Trigger sind toll! So!

Gruesse,

Bio

[Ludger]

Hi,

Man kann in der Datenzugriffsschicht grundsaetzlich alles machen, was die Trigger in der Datenschicht so machen. Ich sehe eigentlich nur einen sinnvollen Einsatz fuer Trigger fuer Alerts (Mitarbeiter X erfahert eine Aenderung des Datenfelds 'Monatsgehalt' in der Mitarbeitertabelle => Mail an den Personalchef.).

Die Datenbank kann auf jeden Fall diese Beschränkungen und Kaskadierungen schnell und zuverlässig ausführen; der aktive Zugriff über SQL kostet mehr.

Performancefragen wuerde ich gerne zuletzt behandeln. Denn erst einmal kostet der Programmierergrips. (Wenn ich da mal einen Tipp an den Nicht-Praktiker(? ;-) geben darf: _unbedingt_ Komplexitaet vermeiden, d.h. moeglichst wenig Komplexitaet hinzubauen)

Allerdings ist meine Meinung da recht unsicher und unbestaetigt. Es ist schon interessant den Datendesigner bestimmte Datenzugriffe (kaskadierende Deletes und Trigger) bereits in seiner Datenschicht durchfuehren zu lasssen. Mein Gegenargument ist die Komplexitaet ("Ein kaskadierendes Delete hat den Delete-Trigger x ausgloest, der wiederum den Delete-Trigger y ausgeloest hat. Nun haben wir alle Datensaetze der Tabelle z geloescht, die im Jahr 1994 angelegt wurden."   :-(   :-)

Wenn Du Angst hast, auf dieser Ebene etwas falsch zu machen (Du hast doch sicher immer ein Backup?), wie kommst Du dann darauf, dass Deine auf höherer Ebene programmierten äquivalenten Mechanismen zuverlässiger und weniger gefährlicher sind bzw. wären?

Ich habe nie Angst davor etwas falsch zu machen.   ;-)
Wir hatten schon mal so "Studis" hier, frisch von der Uni, die haben auch die Einfachheit nicht geschaetzt (und versuchten das mit Sprachgewandheit zu kompensieren). Programmierfehler koennen natuerlich ueberall passieren.

Aber wer kann solche sehr schwierigen Fragen heute noch zuverlaessig beantworten?   ;-)

Wenn überhaupt jemand, dann natürlich ich. Und ich sage: Constraints und Trigger sind toll! So!

Ich wuerde es gerne mal mit einem "aktiven" Datendesign und mit Triggern (die mag ich allerdings weniger) und kaskadierenden Deletes versuchen. Constraints (Du meinst Fremdschluessel und Check-Constraints, vermute ich (fuer die Integritaeten und so)) sind m.E. ebenso etwas zweifelhaft (aeeh, nicht die ref.Integritaet, dafuer bin ich dem RDBMS schon dankbar).

Also, man kann moeglichst viel in der Datenschicht machen oder moeglichst wenig dort (meine bisherieg Empfehlung).

Eine Aufforderung zur Meinungsaeusserung ergeht hiermit!

Gruss,
Ludger

[Bio]

Sup!

Und, wie würdest Du das Problem lösen, die abhängigen Datensätze aus der DB zu schmeissen, wenn eine Person sich aus dem System löscht oder ein Kurs gelöscht wird?

z.B. in einem Anmelde-System für Kurse, z.B. an einer VHS:

Login-Name | passwort-hash | user-id

user-id | Name | eMail

veranstaltungs-id | V.-Name

user-id | veranstaltungs-id

Da braucht es mehr Programmier-Grips, eine Aufräum-Funktion zu schreiben, als die notwendigen Contraints/Trigger für kaskadierendes Löschen zu setzen.

Gruesse,

Bio

[Ludger]

Hi,

Und, wie würdest Du das Problem lösen, die abhängigen Datensätze aus der DB zu schmeissen, wenn eine Person sich aus dem System löscht oder ein Kurs gelöscht wird?

nun, das "abhaengig" ist relativ. Manchmal moechte man die Loeschung, manchmal nicht. Ein falsch gesetztes cascading delete und man hat den Salat.

Darum empfehle ich in der delete stored procedure explizit "abhaengige" und zu loeschende Datensaetze anderer Tabellen anzugeben. Dafuer hat man dann Transaktionen.

Das Problem ist das das Setzen der cascading deletes (manchmal ja, manchmal nein) Geschaeftslogik darstellt und m.E. in der Datenschicht nichts zu suchen hat. Ist doch eine kohaerente Argumentation, vielleicht sogar eine erfolgreiche und richtige.

Aber ich habe da, wie gesagt, keine sehr feste Meinung und darum fragte ich nach Meinungen anderer.

Gruss,
Ludger

[Siechfred]

Привет Bio.

Привет.
Ja, klar, DU MICH AUCH!

Danke für die Blumen.

• Datenhaltung mit Hilfe einer mySQL-Datenbank
  Echte Männer nehmen aber PostGreSQL.

Echte Männer gehen auch zum Weinen in den Keller. Isch 'abe keinen Keller.

• maßvoller Einsatz von BBCode (URL, Bilder, Textformatierung)
  BBCode... so peinlicher Board-Quatsch? Wie tief bist Du gesunken!

Noch nicht tief genug, wie mir scheint.

Total wichtig ist, dass alles extrem wiederverwendbar, objektorientiert und getrennt in Datenhaltungs-, Logik- und Darstellungsschicht ist und ein Interface zu .NET, Tcl, Phyton und mindestens dreissig anderen angesagten Programmiersprachen hat.

Ah ja.

Die Struktur der User-Daten muss in Meta-Daten in XML abgelegt sein, die User-Daten selbst natürlich auch, bzw. sollte die Datenbankabfragen basierend auf den XML-Metadaten on-the-fly erstellt werden, und das Datenbankschema sollte sich automatisch einer Veränderung der Meta-Daten anpassen.

Soso.

Aber nee... ich würde versuchen, sinnvoll zu modularisieren, es aber nicht zu übertreiben, lohnt sich nicht.

Gott sei Dank, ich dachte schon, ich wäre zum Ziel beißender Ironie geworden.

Дружба!
Siechfred

[Ludger]

Hi,

• Datenhaltung mit Hilfe einer mySQL-Datenbank
• Programmiersprache Perl, die Ausgabe mit HTML und etwas Javascript
• sprechende URLs mit Hilfe von mod_rewrite
• Übersicht der Einträge nach Jahr/Monat/Thema
• Neue Einträge sind nur durch mich möglich
• Kommentieren kann jeder, das Löschen unerwünschter Kommentare behalte ich mir vor
• Möglichkeit des Anlegens von Nutzerprofilen
• maßvoller Einsatz von BBCode (URL, Bilder, Textformatierung)

ich wuensche mir noch UTF-8. Und auf das mod_rewrite koennte ich verzichten.

Das wären so meine momentanen Ideen. Fällt euch noch was ein/auf? Sollte ich alles in ein Script packen oder besser mehrere Scripts verwenden oder evtl. eigene Module schreiben? Danke für jede Meinung.

Ein Perlscript reicht.

Gruss,
Ludger

PS: Wieviele Monate planst Du so ein fuer das Projekt?

[Siechfred]

Привет Ludger.

ich wuensche mir noch UTF-8.

Oh, ja, das sollte ich mit einbeziehen.

Ein Perlscript reicht.

Okay.

PS: Wieviele Monate planst Du so ein fuer das Projekt?

Wenn ich alle anderen beiseite schiebe, 1-2.

Дружба!
Siechfred

[Schuer]

Hallo!

Das wären so meine momentanen Ideen. Fällt euch noch was ein/auf?

eine Suche und ein RSS-Feed fände ich noch ganz nett.

Gruß,
_Dirk

[Siechfred]

Привет Schuer.

eine Suche und ein RSS-Feed fände ich noch ganz nett.

Ja, eine Suche sollte es in der Tat geben, allerdings müsste es dazu auch eine entsprechende Menge an zu durchsuchenden Daten geben. Naja, mit RSS habe ich mich noch nicht wirklich beschäftigt, muss also erstmal sehen.

Дружба!
Siechfred

[wahsaga]

hi,

Fällt euch noch was ein/auf?

suche und RSS nannte Dirk ja schon.
was evtl. noch denkbar wäre, wenn du auch ein "hipper" blogger sein willst, der total toll mit den anderen interagiert, wäre natürlich eine "trackback"-funktion.
und dann gibt's da noch so hype-features wie "weblog.com pingen" - heißt nichts groß anderes, als dass beim erstellen eines neuen eintrages eine meldung an das blogverzeichnis weblog.com gesendet wird, dass blogger xy einen neuen furz von sich gegeben hat. und wenn du da nicht bei bist, wer bist du dann ...? eben, ein niemand, und ganz gewiß kein ernstzunehmender blogger!!1

(ja, man merkt's, diesen "features" stehe ich eher ablehnend gegenüber. ich blogge aus spaß an der freud, bei vielen anderen habe ich aber das gefühl, dass sie's für ihr eigenes ego tun, und in tiefem kummer versinken, wenn nicht jeder ihrer hach so gehaltvollen einträge in mindestens einen halben dutzend anderen blogs aufgeriffen wird ...)

Sollte ich alles in ein Script packen oder besser mehrere Scripts verwenden oder evtl. eigene Module schreiben?

soll das script nur für den eigengebrauch sein, oder nachher veröffentlicht werden?
bei ersterem würde ich sagen, ganz allein deine sache.
bei letzterem sollte natürlich die struktur schon leicht verständlich sein, wenn's auch andere leute leicht installieren und modifizieren können sollen. evtl. wäre es dann auch denkbar, dass ganze gleich an eine template-engine zu koppeln, so dass das outputformat leicht modifizierbar ist.

gruß,
wahsaga

[Siechfred]

Привет wahsaga.

was evtl. noch denkbar wäre, wenn du auch ein "hipper" blogger sein willst, der total toll mit den anderen interagiert, wäre natürlich eine "trackback"-funktion.

Nein, kein "hipper" Blogger, dann hätte ich PHP genommen ;)

und dann gibt's da noch so hype-features wie "weblog.com pingen" - heißt nichts groß anderes, als dass beim erstellen eines neuen eintrages eine meldung an das blogverzeichnis weblog.com gesendet wird, dass blogger xy einen neuen furz von sich gegeben hat. und wenn du da nicht bei bist, wer bist du dann ...? eben, ein niemand, und ganz gewiß kein ernstzunehmender blogger!!1

Naja, nicht wirklich essentiell, gelle :)

soll das script nur für den eigengebrauch sein, oder nachher veröffentlicht werden?

Für den Eigengebrauch, i.e.S. aus Spaß an der Programmierung. Also entnehme ich deinen Ausführungen, dass eigentlich alles Wesentliche drin ist (außer Suche und RSS)?

Дружба!
Siechfred

[wahsaga]

hi,

Nein, kein "hipper" Blogger, dann hätte ich PHP genommen ;)

grrr ...

Für den Eigengebrauch, i.e.S. aus Spaß an der Programmierung. Also entnehme ich deinen Ausführungen, dass eigentlich alles Wesentliche drin ist (außer Suche und RSS)?

mir fällt spontan nichts weiteres ein, was sonst noch "unbedingt" gebraucht würde ... außer inhalten natürlich :-)

gruß,
wahsaga

[Siechfred]

Привет wahsaga.

Nein, kein "hipper" Blogger, dann hätte ich PHP genommen ;)
grrr ...

Oh, fühlst du dich etwa angesprochen? ;))
Nee, im Ernst, um meine Neurosen pflegen zu können (Stichworte Spamschutz, doppeltes Absenden, Abfangen von Fehlern etc.), müsste ich mich intensiver mit PHP beschäftigen (für einen Formmailer hat's gerade so gereicht), in Perl bin ich auf dieser Schiene etwas sicherer. Das ist der Grund für Perl :)

Дружба!
Siechfred

[Jeena Paradies]

Hallo,

Nein, kein "hipper" Blogger, dann hätte ich PHP genommen ;)
grrr ...
Oh, fühlst du dich etwa angesprochen? ;))

Ich dachte immer dass eigentlich nur Hauptschüler wie ich PHP nehmen, dass dies auch "hippe" Blogger machen wusste ich ja gar nicht. Hm oder sind alle "hippen" Blogger Hauptschüler?

Grüße
Jeena Paradies

[wahsaga]

hi,

Ich dachte immer dass eigentlich nur Hauptschüler wie ich PHP nehmen, dass dies auch "hippe" Blogger machen wusste ich ja gar nicht. Hm oder sind alle "hippen" Blogger Hauptschüler?

wenn man sich den gehalt so mancher kiddieblog-einträge so ansieht ... *g*
aber eigentlich ist es müssig, darüber zu "lästern". soll halt jeder bloggen, was und worüber er will.

und die ständigen diskussionen darüber, ob ein weblog nun ein "echtes" weblog sei (weil es inhalte von anderswo aufgreift und kommentiert), oder ob es nur ein "web diary" sei (weil es hauptsächlich um persönliches geht), ist mir auch über.
da mag sich die selbsternannte weblog-elite mit beschäftigen, mir ist's wurscht. soll jeder bloggen, was ihm passt - und nur einfach nicht erwarten, dass es jeden interessiert - oder gar einen solchen anspruch deklarieren.

witzig auch, wenn heise mal wieder irgendeinen mit weblogs im zusammenhang stehenden artikel bringt - wie sie sich im forum dann alle darüber aufregen, wie nichtssagend und einbedeutend die meisten blogs wären, dass der privatkram eh keine sau interessieren würde, etc. - so what?

gruß,
wahsaga

[wahsaga]

hi,

Oh, fühlst du dich etwa angesprochen? ;))

nein, nicht wirklich :-)

Nee, im Ernst, um meine Neurosen pflegen zu können (Stichworte Spamschutz, doppeltes Absenden, Abfangen von Fehlern etc.), müsste ich mich intensiver mit PHP beschäftigen (für einen Formmailer hat's gerade so gereicht), in Perl bin ich auf dieser Schiene etwas sicherer. Das ist der Grund für Perl :)

bei mir ist andersherum.

gruß,
wahsaga

[Siechfred]

Привет.

Ergänzungsfrage zu Datenhaltung, folgende Struktur habe ich mir überlegt:

Datenbank:
 Tabelle Nachrichten
  Feld ID der Nachricht
  Feld Anzahl der Kommentare
 Tabelle Kommentare
  Feld ID des Kommentars
  Feld ID der bezogenen Nachricht
  Feld ID des Autors
 Tabelle Inhalt
  Feld ID der Nachricht oder des Kommentars
  Feld Inhalt
 Tabelle Autoren
  Feld ID des Autors
  Felder über den Autor (was halt so interessant ist, was meint ihr?)

Die IDs der Nachrichten und Kommentare würde ich aus dem aktuellen Datum und der aktuellen Zeit generieren, sodass mir über diesen Weg diese Informationen ohne ein weiteres Datenfeld zur Verfügung stünden.

Scheint euch das ein gangbarer Weg oder habe ich bei o.g. Struktur irgendwo Denk- bzw. Konzeptfehler drin?

Дружба!
Siechfred

[wahsaga]

hi,

Ergänzungsfrage zu Datenhaltung, folgende Struktur habe ich mir überlegt:

Tabelle Nachrichten
  Feld ID der Nachricht
  Feld Anzahl der Kommentare

anzahl kommentare hatte ich bei meinem blog anfangs auch direkt an der nachricht gespeichert. erfordert dann natürlich bei jedem neuen kommentareintrag auch ein hochzählen an dieser stelle, also updates in zwei tabellen statt nur einer. wenn du es wirklich genau nehmen willst, kommt dadurch also auch noch eine notwendigkeit für transaktionen ins spiel, denn wenn das eintragen eines neuen kommentars geklappt hat, das updaten der einträge-tabelle aber nicht, hättest du ja einen datenschiefstand.

inzwischen bin ich dann doch lieber dazu übergegangen, die anzahl der kommentare zu einem blogeintrag aus der kommentartabelle selbst zu ermitteln, also bei der abfrage einen entsprechenden JOIN zu machen. wozu bietet eine DB schließlich solche möglichkeiten ...

Tabelle Kommentare
  Feld ID des Kommentars
  Feld ID der bezogenen Nachricht

auf diese spalte habe ich noch einen index gesetzt, der bei oben erwähntem join benutzt werden kann.

Tabelle Autoren
  Feld ID des Autors
  Felder über den Autor (was halt so interessant ist, was meint ihr?)

hm, ich dachte blogeinträge schreiben wolltest nur die selber?
also wäre diese tabelle dann für die kommentarschreiber gedacht - die sich demnach dann auch erstmal registrieren müssten ...?
registrierungszwang zum kommentieren schreckt meistens eher ab, würde ich also drauf verzichten, sofern sich nicht im laufe der zeit herausstellen sollte, dass allzu starker missbrauch mit der kommentarfunktion (spam, beleidigungen, etc.) betrieben wird.

informationen zum jeweiligen autor liegen bei mir mit in der kommentartabelle, also name, homepage, email. braucht man sonst noch was? ich denke nicht, viel mehr wäre overkill.
darüber hinaus neigen "meine" kommentierer dazu, nicht immer den selben namen, homepage etc. anzugeben, sondern bspw. manchmal einen ironisch gemeinten namen mit bezug auf den aktuellen blogeintrag zu wählen (obwohl die person natürlich die selbe ist). was würdest du dann machen - einen _neuen_ autor dafür in deiner tabelle anlegen?

Tabelle Inhalt
  Feld ID der Nachricht oder des Kommentars
  Feld Inhalt

ich habe blogeinträge und kommentare direkt in ihren jeweiligen tabellen gespeichert, weil ihre struktur doch unterschiedlich ist.
blogeinträge haben nur überschrift und text, sowie noch das datum - autor bin immer ich *g*, also muss der nicht gesondert vermerkt werden.
ggf. käme hier noch eine kategorie-ID hinzu (sofern man denn seine blogeinträge in verschiedene solche aufteilen will - für mein blog sehe ich keinen nutzen darin) - auch wieder ein merkmal, dass die kommentare eigentlich nicht haben.

die kommentare haben dann blogeintrags-ID, autorname, -homepage, -email sowie text und datum.

Die IDs der Nachrichten und Kommentare würde ich aus dem aktuellen Datum und der aktuellen Zeit generieren, sodass mir über diesen Weg diese Informationen ohne ein weiteres Datenfeld zur Verfügung stünden.

würde ich leicht unsauber finden, zwei kommentare zum exakt selben zeitpunkt wären ja zumindest theoretisch denkbar.
da nutze ich doch lieber eine einfache auto_increment-ID-spalte, und lege das datum seperat ab.

tipp zum speichern des datums: einen der von mysql bereitgestellten datumstypen zu nutzen, wäre sicher vorteilhaft - erleichtert nachher die sortierung bzw. auswahl bspw. nach monaten für's archiv.

Scheint euch das ein gangbarer Weg oder habe ich bei o.g. Struktur irgendwo Denk- bzw. Konzeptfehler drin?

dein weg wäre m.E. durchaus gangbar, auch wenn meiner wie beschrieben davon abweicht.
könnte allerdings auch durchaus eine geschmacksfrage sein ...

gruß,
wahsaga

[Siechfred]

Привет wahsaga.

anzahl kommentare hatte ich bei meinem blog anfangs auch direkt an der nachricht gespeichert. erfordert dann natürlich bei jedem neuen kommentareintrag auch ein hochzählen an dieser stelle, also updates in zwei tabellen statt nur einer. wenn du es wirklich genau nehmen willst, kommt dadurch also auch noch eine notwendigkeit für transaktionen ins spiel, denn wenn das eintragen eines neuen kommentars geklappt hat, das updaten der einträge-tabelle aber nicht, hättest du ja einen datenschiefstand.

Ja, da ist was dran.

Tabelle Autoren
hm, ich dachte blogeinträge schreiben wolltest nur die selber?

Ja, dem ist auch so, deswegen gibt es in der Tabelle "Nachrichten" auch keine Autoren-ID. Die Tabelle "Autoren" ist eher dafür gedacht, falls jemand der Meinung ist, er möchte mehr Infos über sich präsentieren. Dann kann er hier die Daten hinterlegen, ansonsten besteht ein Eintrag eben nur aus ID und Nick.

also wäre diese tabelle dann für die kommentarschreiber gedacht - die sich demnach dann auch erstmal registrieren müssten ...?

Nein, das soll - wenn überhaupt - ein optionales Feature sein. Aber vielleicht lasse ich es auch ganz weg. Ein Registrierungszwang ist kontraproduktiv, das ist mir klar.

informationen zum jeweiligen autor liegen bei mir mit in der kommentartabelle, also name, homepage, email. braucht man sonst noch was? ich denke nicht, viel mehr wäre overkill.

Ja, so in etwa stellte ich mir das mit der Tabelle "Autor" vor.

ich habe blogeinträge und kommentare direkt in ihren jeweiligen tabellen gespeichert, weil ihre struktur doch unterschiedlich ist. blogeinträge haben nur überschrift und text, sowie noch das datum - autor bin immer ich *g*, also muss der nicht gesondert vermerkt werden.

Klar, deshalb ja auch die Tabellen "Nachrichten" und "Kommentare". Ich dachte mir, dass ich mit der Tabelle "Nachrichten" einsteige, mit der ID der Nachricht in die Tabelle "Kommentare" gucke, falls es Kommentare gibt, deren ID merke und dann in der Tabelle "Inhalt" den Text der Nachrichten abfrage. Dabei ist es in letztgenannter egal, ob Kommentar oder Nachricht.

ggf. käme hier noch eine kategorie-ID hinzu (sofern man denn seine blogeinträge in verschiedene solche aufteilen will - für mein blog sehe ich keinen nutzen darin) - auch wieder ein merkmal, dass die kommentare eigentlich nicht haben.

Naja, Kategorien sind eigentlich aus meiner Sicht nur sinnvoll, wenn man ein Massenblogger ist und - was weiß ich - 10 Einträge am Tag verfasst.

würde ich leicht unsauber finden, zwei kommentare zum exakt selben zeitpunkt wären ja zumindest theoretisch denkbar. da nutze ich doch lieber eine einfache auto_increment-ID-spalte, und lege das datum seperat ab.

Ja, da ist was dran.

Danke für die ausführliche Antwort :)

Дружба!
Siechfred

[wahsaga]

hi,

Klar, deshalb ja auch die Tabellen "Nachrichten" und "Kommentare". Ich dachte mir, dass ich mit der Tabelle "Nachrichten" einsteige, mit der ID der Nachricht in die Tabelle "Kommentare" gucke, falls es Kommentare gibt, deren ID merke und dann in der Tabelle "Inhalt" den Text der Nachrichten abfrage. Dabei ist es in letztgenannter egal, ob Kommentar oder Nachricht.

sicher, das lässt sich machen, wenn die struktur von blogeinträgen und kommentaren gleich oder zumindest sehr identisch ist.

wenn du also informationen zum autor separat ablegst, wäre das denkbar.

aber zum beispiel bei meinem modell wäre das unsinnig, weil sich meine einträge und die kommentare vom format bzw. datenumfang einfach zu sehr unterscheiden.
dadurch, dass ich alle nötigen informationen jeweils direkt in den jeweiligen tabellen (blogeinträge und kommentare) ablege, entfällt bei mir dann wiederum der weg über die zusätzliche tabelle "nachrichten" ...

gruß,
wahsaga

[Jeena Paradies]

Hallo,

Du hast irgendwie sehr viele Tabellen. Vor allem das mit dem Autor würde ich eigentlich eher in eine Textdatei/XML Datei packen, da sich das ja nicht so oft verändert oder?

Meine zwei Tabellen sehen so aus:

Tabelle content:

id (auto_increment)
topic
date (datetime)
teaser
keywords
content

Tabelle comments:

sid (besteht aus Timestamp + IP zur eventuellen weiterverwertung bei Missbrauch, Beleidigung)
name
city
email
homepage
content
date (datetime)
reference (die ID des Eintrages in der contents Tabelle)
mail_by_comment (ob bei neuem Kommentar der Kommentarschreiber benachrichtigt werden will)

Ja und das war es schon. Ich habe da bei content zwar noch teaserpic und teaserpiconblog, welche dann die URL zum Teaserbild speichern, und die Info ob das auch im richtigen Eintrag angezeigt werden soll, aber das ist nicht so wichtig.

Grüße
Jeena Paradies

[Jeena Paradies]

Hallo,

argh, hier habe ich noch etwas vergessen

Tabelle comments:

id (auto_increment, wird auch als id des Kommentares in der HTML Seite eingesetzt, damit man genau den Kommentar anspringen kann.)
sid (ist auch noch dazu da um doppelte Abschicken zu verhindern.)

Grüße
Jeena Paradies

[Ludger]

Hi,

Du hast irgendwie sehr viele Tabellen. Vor allem das mit dem Autor würde ich eigentlich eher in eine Textdatei/XML Datei packen, da sich das ja nicht so oft verändert oder?

die Autoren sind, wenn ich richtig verstanden habe, nur fuer die Kommentare auf die Beitraege des Meisters vorgesehen (Siechfreds Steuertipps fallen mir da so ein oder seine kompetenten Aeusserungen zu Rechtsfragen :-). Also muessen sich die Autoren irgendwie zu erkennen geben, also registrieren (vielleicht werden die dann auch erst noch nach einer Pruefung freigeschaltet? ;-). Vermutlich ist also Sicherheit zu implementieren mithilfe der typischen Entitaten "Sitzungen" (Identifikation), "Nutzer" (Authentifikation) und "Rechte" (Autorisierung). Das ist schon ein Job fuers RDBMS. Nur strukturierte Daten, die immer wieder in unterschiedlichen Strukturen kommen, waeren m.E. hier etwas "fuer XML".

Gruss,
Ludger

[Jeena Paradies]

Hallo,

Nur strukturierte Daten, die immer wieder in unterschiedlichen Strukturen kommen, waeren m.E. hier etwas "fuer XML".

Ich stehe hier gerade vor so einem Fall wo ich nicht so richtig weiß wie ich es am besten löse. Ich will so ein Admincenter bauen, in dem man gewisse Daten die die Seite angehen abspeichern kann. Bisher habe ich es einfach in einer PHP Datei, die man nur mit einem Texteditor bearbeiten kann und dann per FTP hochladen kann:

<?php
 $m['website']          = "Neues Blog";
 $m['publisher']        = "Jeena Paradies";
 $m['webmastermail']    = "[e-mail]";
 $m['description']      = "Ein neues Blog über alles mögliche.";
 $m['max_blog_orginal'] = 1;
 $m['max_blog_big']     = 2;
 $m['max_blog_small']   = 17;
 $m['sub_current']      = 4;
 $m['info_by_comment']  = 1;
 $m['basepath']         = "/home/jeena/Webs/jlog-0.2";
 $m['path']             = "http://localhost/open/Webs/jlog-0.2";
 $m['db_content']       = "content";
 $m['db_comments']      = "comments";
 $m['db']               = "blog";
 $m['db_url']           = "localhost";
 $m['db_user']          = "dbuser";
 $m['db_pwd']           = "password";
 $m['date']             = "'%d.%m.%Y'";
 $m['e404_path']        = "/inc/error404.php";
?>

Bei einem anderen Projekt habe ich es eigentlich genau so gemacht, nur dass ein Script genau diese Datei aus den in einem Formular eingegebenen Daten macht und dann gleich auf dem Server ablegt. Ist das die beste Lösung für so etwas?

Grüße
Jeena Paradies

[Ludger]

Hi,

Nur strukturierte Daten, die immer wieder in unterschiedlichen Strukturen kommen, waeren m.E. hier etwas "fuer XML".
Ich stehe hier gerade vor so einem Fall wo ich nicht so richtig weiß wie ich es am besten löse. Ich will so ein Admincenter bauen, in dem man gewisse Daten die die Seite angehen abspeichern kann.

nun, es haengt von den "gewissen Daten" ab. Ist die Struktur bekannt, dann kommt man mit "RDBMS-Design", ist das einzige, was ueber die Strukur bekannt ist, dass es eine Struktur ist, dann muss man mit "XML-Datenhaltung" kommen.

"XML-Datenhaltung" hat den Vorteil, dass man fast alle (?) strukturierten Daten halten kann und den Nachteil, dass man (zumindest ohne Schema) nicht weiss, was man hat, was sich gerade auch beim Datenzugriff unguenstig auswirken kann.   ;-)

Gruss,
Ludger

[Siechfred]

Привет Jeena.

Du hast irgendwie sehr viele Tabellen. [...] Meine zwei Tabellen sehen so aus: [...]

Mir scheint mittlerweile auch, dass ich es zu kompliziert angehen will. Jedenfalls werde ich die Struktur noch mal überdenken.

Дружба!
Siechfred

[Ludger]

Hi,

Datenbank:
Tabelle Nachrichten
  Feld ID der Nachricht
  Feld Anzahl der Kommentare

die Anzahl wuerde ich hier nicht speichern. Allerdings den Text der Nachricht.

Tabelle Kommentare
  Feld ID des Kommentars
  Feld ID der bezogenen Nachricht
  Feld ID des Autors

Warum den Text der Nachricht nicht hier speichern? Trennung von Struktur und Inhalt?   ;-)

Tabelle Inhalt
  Feld ID der Nachricht oder des Kommentars
  Feld Inhalt

Tabelle ueberfluessig? Verzeigerung "wild"?

Tabelle Autoren
  Feld ID des Autors
  Felder über den Autor (was halt so interessant ist, was meint ihr?)

Die IDs der Nachrichten und Kommentare würde ich aus dem aktuellen Datum und der aktuellen Zeit generieren, sodass mir über diesen Weg diese Informationen ohne ein weiteres Datenfeld zur Verfügung stünden.

IDs sollte man aber nicht mit Bedeutung belegen. Es spricht nichts gegen zusaetzliche "Zeitstempel"-Felder.

Scheint euch das ein gangbarer Weg oder habe ich bei o.g. Struktur irgendwo Denk- bzw. Konzeptfehler drin?

Noeeh, noe.

Gruss,
Ludger

[wahsaga]

hi,

Lude und ich vollkommen einer meinung - das gibt ein rotes X im kalender :-)

gruß,
wahsaga

[Ludger]

Hi,

Lude und ich vollkommen einer meinung - das gibt ein rotes X im kalender :-)

im Datendesign muss man ja auch fast einer Meinung sein, denn das Design ergibt sich Analyse des nachzubildenden realen Sachverhalts so zu sagen zwingend. Man muss die Entitaeten erkennen (hier: Inhalt ist keine Entitaet sondern Attribut, eventuell sind Beitrag und Kommentar von derselben Herkunft?, Autoren der Kommentare sind eine Entitaet, eventuell sind auch Autoren der Beitraege angefordert? u.s.w.) und deren Attribute und Beziehungen.
Merke: Datendesign ist einfach

Gruss,
Ludger

PS: Aber manche moegens ja komplizierter.

[Siechfred]

Привет Ludger.

Tabelle Nachrichten
  Feld ID der Nachricht
  Feld Anzahl der Kommentare
die Anzahl wuerde ich hier nicht speichern. Allerdings den Text der Nachricht.

Ja, ich denke, dass mein Konzept hier noch verbesserungswürdig ist.

Tabelle Kommentare
  Feld ID des Kommentars
  Feld ID der bezogenen Nachricht
  Feld ID des Autors
Warum den Text der Nachricht nicht hier speichern? Trennung von Struktur und Inhalt?   ;-)

Ja, wahrscheinlich ist man schon zu HTML/CSS-versaut :)

Die IDs der Nachrichten und Kommentare würde ich aus dem aktuellen Datum und der aktuellen Zeit generieren, sodass mir über diesen Weg diese Informationen ohne ein weiteres Datenfeld zur Verfügung stünden.
IDs sollte man aber nicht mit Bedeutung belegen. Es spricht nichts gegen zusaetzliche "Zeitstempel"-Felder.

Gut, dann werde ich es wohl besser so machen. Danke für die Hinweise.

Дружба!
Siechfred

[Ludger]

Hi,

Warum den Text der Nachricht nicht hier speichern? Trennung von Struktur und Inhalt?   ;-)

Ja, wahrscheinlich ist man schon zu HTML/CSS-versaut :)

Datendesign ist eine uebel schwere Sache. Muesste Dir aber liegen als Anwalt(?).

Gruss,
Ludger

[Jeena Paradies]

Hallo,

Was vielleicht zukünftig eventuell benötigt werden würde ist die Leichte möglichkeit Spamschutz einzubauen. Viele sind von Kommentarspam so sehr belagert, dass da zeitweise 400 Spamkommenare innerhalb von 24 Stunden eintrudeln.

Allerdings habe ich persönlich noch keinen einzigen automatisch generierten Spamkommentar innerhalb meiner eigenen Blogsoftware bekommen.

Grüße
Jeena Paradies

[wahsaga]

hi,

Allerdings habe ich persönlich noch keinen einzigen automatisch generierten Spamkommentar innerhalb meiner eigenen Blogsoftware bekommen.

die wahrscheinlichkeit scheint sich auch durch den einsatz von "standard"-blogsoftware massiv zu erhöhen. in meinem selbstgeschriebenen blogscript hatte ich bisher auch noch _keinen einzigen_ solchen fall. aber vielleicht liegt's ja auch nur daran, dass mein blog zu unbedeutend und der PR meiner seite zu gering ist :-)

nein, ernsthaft: mit "individueller" blogsoftware halte ich das risiko für sehr gering.

von leuten mit "bekannter" blogsoftware höre/lese ich das öfters. insbesondere wird des öfteren in einträgen gespamt, die längst nicht mehr aktuell sind - in der hoffnung, dass es dem betreiber dann nicht so leicht auffällt, aber bei den SuMas, die sich auch noch durchs archiv eines solchen blogs crawlen, das ranking der "beworbenen" seiten erhöht.
da ich mich über jeden neuen kommentar per mail benachrichtigen lasse, würde ich aber auch das merken.
bei mancher standardsoftware werden aber wegen dieses problems inzwischen schon plugins angeboten, die sofortiges kommentieren nur bei aktuellen einträgen ermöglichen - bei kommentaren zu älteren einträgen wird dann eine explizite freischaltung des kommentars durch den blogbetreiber erforderlich.

außerdem wandle ich in meinen kommentaren keine links um, solcher spam könnte also höchstens noch über die angabe der homepage-URL des autors erfolgreich sein.

ein weiteres spam-problem, dass sich in solchen blog oft ergibt, hängt mit der gerne vorgenommenen anzeige der häufigsten "backlinks" zusammen - also schlicht gesagt eine auflistung der referrer, von denen die besucher kommen. darin zu spammen, durch schlichte anfragen mit gefälschtem referrer, wird häufig versucht - oftmals für xxx-seiten - vermutlich ebenfalls mit dem ziel, damit den PR zu erhöhen. das habe ich in meinem blog auch schon festgestellt, obwohl ich die referrer gar nicht in dieser weise auswerte. hab's dann trotzdem wie beschrieben unterbunden, weil's mir einfach auf den nerv ging, dass diese bots sich durch mein komplettes archiv frassen ...

gruß,
wahsaga

[Tim Tepaße]

Hallo Siechfred,

ich schreibe mal auf, was eventuell noch dazu kommen könnte, aber nicht
wirklich für ein Weblog benötigt wird, also Luxusoptionen. »Eigentlich«
besteht ein Weblog ja nur aus ein paar HTML-Seiten in einer bestimmten
Ordnung, kann man im Prinzip ja wunderbar mit nur einem HTML-Editor basteln.

• Datenhaltung mit Hilfe einer mySQL-Datenbank
• Programmiersprache Perl, die Ausgabe mit HTML und etwas Javascript

Darf ich nachfragen, wofür Javascript? Ich hab zwar in der Vergangenheit
einige interessante Weblogkonzepte gesehen, in denen JS bespielsweise für
ein dynamisches Nachladen von Kommentaren benutzt werden, aber solch
komplizierte DHTML-Varianten kann ich mir bei einem von Forum erzogenen
eigentlich weniger vorstellen. Reine Neugierde hier.

Die dynamische Struktur erspart Dir jedenfalls bei einer Designänderung
den kompletten Rebuild der Seite, bei älteren Weblogskripts (Greymatter,
Movable Type, Blogger.com), die aus Templates direkt HTML-Seiten kreiierten
war das immer extrem nervtötend bis hin, daß der Hoster den Prozess tötete.

Etwas templatebasiertes solltest Du wirklich in Betracht ziehen, zu oft
will man dann hinterher etwas ändern, ohne im Skript rumzufummeln. Da
gibt es doch auch irgendwas Perl, nicht?

• Übersicht der Einträge nach Jahr/Monat/Thema

Bei Kategorien besteht auch noch die Möglichkeit hierarchischer Kategorien
wie zum Beispiel bei Tim Bray oder multipler Kategorien (»Tags«), wie
neuerdings auch bei GMail oder iTunes beliebt. Für ein Einpersonenweblog
ist das aber oft Overkill.

Früher (zu Zeiten von Blogger.com) waren archiviertee Einträge auf Monats-
oder Wochenseiten sehr beliebt, seit einigen Jahren geht der Trend zu dem
Prinzip »Ein Eintrag - eine Seite«, was auch den Vorteil hat, daß man
die Kommentare dort darstellen kann und nicht mit irgendwelchen lästigen
Popups rumhantieren muß. Je nach Weblog kann man noch Archivseiten für den
konkreten Tag der Einträge anlegen, das hängt aber natürlich vom eigenen
Postingaufkommen ab.

• Neue Einträge sind nur durch mich möglich

An Deiner Stelle würde ich die entsprechenden Eingabeskripte einfach durch
.htaccess schützen, anstatt mir komplizierte Nutzerverwaltungsvarianten
auszudenken, schließlich soll es ja nur ein Weblogskript für Dein Weblog
sein, kein CMS-ähnliches Gebilde, nicht?

• Kommentieren kann jeder, das Löschen unerwünschter Kommentare behalte
  ich mir vor

Was dabei für Dich praktisch sein könnte: Eine Übersicht aller zuletzt
abgegebenen Kommentare, um nicht jedesmal die aktuellen Eintragsseiten
durchgehen zu müssen. RSS nutzende machen das dann per RSS-Feed. Auch
ist es Usus, daß Einträge, die seit einiger Zeit nicht mehr aktuell sind
(z.B.: Nicht mehr auf der Startseite des Weblogs stehen) nicht mehr
kommentierbar sind. Erspart einem, daß irgendjemand über dem ganzen Archiv
mit einem Skript Kommentarspam verteilt, auch wenn Kommentarspam bei einem
selbstgeschriebenen Skript eher selten sein sollte.

• Möglichkeit des Anlegens von Nutzerprofilen

Ähm. Ja. Als potentieller Leser des Weblogs wäre ich da nicht so ein Fan
von, wenn das heißt, daß man unregistriert nicht kommentieren kann. Die
für jeden offene Kommentarmöglichkeit ist für viele sehr wichtig, wer will
schon sich für dutzende von Weblogs jeweils registrieren müssen? Ausnahmen
sind meist die Weblogs-Communities wie z.B. Antville, wo der registrierte
Name weblogübergreifend gilt. Parallel zur offenen Kommentarmöglichkeit
sind Nutzerprofile natürlich kein Problem.

• maßvoller Einsatz von BBCode (URL, Bilder, Textformatierung)

Ich würde da HTML vorziehen, aber das ist natürlich Geschmackssache.

Das wären so meine momentanen Ideen. Fällt euch noch was ein/auf?

• RSS/Atom-Feed halte ich inzwischen für unverzichtbar, dann aber bitte
  Full Posts im Feed, nicht nur Überschriften oder Teaser. Wurde zwar schon
  genannt, aber hey.

• Da es Dein Weblog auf Deinem Webspace ist, ist das vielleicht nicht so
  wichtig, aber eine Upload-Möglichkeit für Bilder und ähnliches wäre vielleicht
  praktisch.

...

Und nun etwas mehr oder weniger unnötiges Luxuszeug:

• »Wer linkt auf mich« ist in der Blogosphäre eine anscheinend sehr wichtige
  Frage. Einige machen das, indem sie die Referrer auswerten. Und dann gibt
  es die beiden gewollten Lösungen, Trackback und Pingback. Ersteres ist
  populärer, aber auch schwieriger bei der Implementierung von Auto-Discovery,
  Henryk hat da mal eine Beschwerde drüber geschrieben. Als Hardcorevariante habe
  ich auch schon Weblogs gesehen, die auf Technorati zugreifen, das ist aber
  extremes Exotentum.

• Was 2001 mal sehr populär war, war Greymatters Karma, einfach eine
  Bewertung des Beiträgs, wie hier im Forum. Sieht man aber kaum noch mehr.

• Fast schon absurde Extras: Wenn ein Kommentator eine Homepage angibt,
  diese nach einem Favicon durchsuchen und das bei sich einbinden, und
  ähnliche Schmankerl.

• Etwas, um das ich nie mein Hirn winden konnte: die Unterstützung externer
  Services wie Flickr, delecious, Amazon API. Wer's mag.

• Polls, wobei die natürlich wieder nach einer Registrierung schreien.

• Wenn man nicht im Browserfenster schreiben will, ist Unterstützung einer
  API zum Zugriff externer Weblogeditoren auf das eigene Weblog vielleicht
  interessant. APIs wären die MetaWeblog API oder in Zukunft vielleicht die
  Atom API, dann könnte man seine Einträge in schönen Programmen wie Ecto
  oder Marsedit schreiben.

Tim

[Siechfred]

Привет Tim.

Darf ich nachfragen, wofür Javascript?

Nur für die komfortablere Benutzbarkeit des Eingabeformulars, mehr nicht.

Etwas templatebasiertes solltest Du wirklich in Betracht ziehen, zu oft
will man dann hinterher etwas ändern, ohne im Skript rumzufummeln. Da
gibt es doch auch irgendwas Perl, nicht?

*g* ja, z.B. das Modul HTML::Template.

An Deiner Stelle würde ich die entsprechenden Eingabeskripte einfach durch
.htaccess schützen, anstatt mir komplizierte Nutzerverwaltungsvarianten
auszudenken, schließlich soll es ja nur ein Weblogskript für Dein Weblog
sein, kein CMS-ähnliches Gebilde, nicht?

Ja, .htaccess war meine erste Wahl für diesen Teil.

Auch ist es Usus, daß Einträge, die seit einiger Zeit nicht mehr aktuell sind (z.B.: Nicht mehr auf der Startseite des Weblogs stehen) nicht mehr kommentierbar sind.

Ja, guter Hinweis, danke.

• Möglichkeit des Anlegens von Nutzerprofilen
  Ähm. Ja. Als potentieller Leser des Weblogs wäre ich da nicht so ein Fan
  von, wenn das heißt, daß man unregistriert nicht kommentieren kann.

Nein, soll nur ein Gimmick sein. Wer mehr über sich preisgeben möchte kann das tun, wer nicht, schreibt halt anonym.

• RSS/Atom-Feed halte ich inzwischen für unverzichtbar, dann aber bitte
  Full Posts im Feed, nicht nur Überschriften oder Teaser. Wurde zwar schon
  genannt, aber hey.

Wie schon geschrieben, RSS ist für mich noch absolutes Neuland, steht also ganz unten in der Prioritätenliste.

• Da es Dein Weblog auf Deinem Webspace ist, ist das vielleicht nicht so
  wichtig, aber eine Upload-Möglichkeit für Bilder und ähnliches wäre vielleicht
  praktisch.

Hm, mal schauen.

• »Wer linkt auf mich« ist in der Blogosphäre eine anscheinend sehr wichtige Frage.

Ja? Nun, das interessiert mich eigentlich weniger, sodass mir ein gelegentlicher Blick ins Serverlog eigentlich reicht.

• Was 2001 mal sehr populär war, war Greymatters Karma, einfach eine Bewertung des Beiträgs, wie hier im Forum.

Naja, muss in einem Blog m.E. nicht unbedingt sein.

• Fast schon absurde Extras: Wenn ein Kommentator eine Homepage angibt,
  diese nach einem Favicon durchsuchen und das bei sich einbinden, und
  ähnliche Schmankerl.

Hm, halte ich in der Tat für etwas übertrieben :)

Danke für deine umfangreichen Hinweise.

Дружба!
Siechfred

[Jeena Paradies]

Hallo,

• Fast schon absurde Extras: Wenn ein Kommentator eine Homepage angibt,
  diese nach einem Favicon durchsuchen und das bei sich einbinden, und
  ähnliche Schmankerl.

ja wie zum Beispiel: http://www.gravatar.com/ 80px x 80px Bildchen hochladen und es erscheint in allen Weblogs neben deinem Kommentar, die das unterstützen ;-)

Grüße
Jeena Paradies

[Siechfred]

Привет.

Vielen Dank für die zahlreichen Hinweise. Ich werde mich dann mal an die Beta-Version wagen :)

Дружба!
Siechfred