Siechfred: Welche Features sollte ein Webblog haben?

0 50

Welche Features sollte ein Webblog haben?

Siechfred
  • meinung
  1. -1
    Bio
    1. 0
      Ludger
      1. 0
        Bio
    2. 0
      Jörg Peschke
      1. 0
        Bio
        1. 0
          Jörg Peschke
          1. 0
            Bio
            1. 0
              Ludger
              1. 0
                Bio
                1. 0
                  Ludger
                  1. 0
                    Bio
                    1. 0
                      Ludger
                      1. 0
                        Bio
                        1. 0
                          Ludger
                          1. 0
                            Bio
                            1. 0
                              Ludger
    3. 0
      Siechfred
  2. 1
    Ludger
    1. 0
      Siechfred
  3. 1
    Schuer
    1. 0
      Siechfred
  4. 1
    wahsaga
    1. 0
      Siechfred
      1. 0
        wahsaga
        1. 0
          Siechfred
          1. 0
            Jeena Paradies
            1. 0
              wahsaga
          2. 0
            wahsaga
  5. 0

    Ergänzungsfrage zur DB-Struktur

    Siechfred
    1. 0
      wahsaga
      1. 0
        Siechfred
        1. 0
          wahsaga
    2. 0
      Jeena Paradies
      1. 0
        Jeena Paradies
      2. 0
        Ludger
        1. 0
          Jeena Paradies
          1. 0
            Ludger
      3. 0
        Siechfred
    3. 0
      Ludger
      1. 0
        wahsaga
        1. 0
          Ludger
      2. 0
        Siechfred
        1. 0
          Ludger
  6. 0
    Jeena Paradies
    1. 0
      wahsaga
  7. 1

    Welche Features könnte ein Weblog haben?

    Tim Tepaße
    1. 0
      Siechfred
    2. 0
      Jeena Paradies
  8. 0

    Danke

    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

--
»Sie kochten heimlich mit Wasser und tranken öffentlich Wein.«
  1. 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

    --
    Keep your friends close, but your enemies closer!
    1. 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

      1. 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

    2. 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 ;)

      1. 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

        1. 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

          1. 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

            1. 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

              1. 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

                1. 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

                  1. 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

                    --
                    Keep your friends close, but your enemies closer!
                    1. 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

                      1. 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

                        --
                        Keep your friends close, but your enemies closer!
                        1. 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

                          1. 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

                            --
                            Keep your friends close, but your enemies closer!
                            1. 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

    3. Привет 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

      --
      »Sie kochten heimlich mit Wasser und tranken öffentlich Wein.«
  2. 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?

    1. Привет 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

      --
      »Sie kochten heimlich mit Wasser und tranken öffentlich Wein.«
  3. 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

    1. Привет 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

      --
      »Sie kochten heimlich mit Wasser und tranken öffentlich Wein.«
  4. 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

    --
    "Look, that's why there's rules, understand? So that you _think_ before you break 'em."
    1. Привет 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

      --
      »Sie kochten heimlich mit Wasser und tranken öffentlich Wein.«
      1. 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

        --
        "Look, that's why there's rules, understand? So that you _think_ before you break 'em."
        1. Привет 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

          --
          »Sie kochten heimlich mit Wasser und tranken öffentlich Wein.«
          1. 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

            --
            Testbrowser Konqueror auch Webdesigner ohne Linux können darauf testen
            1. 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

              --
              "Look, that's why there's rules, understand? So that you _think_ before you break 'em."
          2. 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

            --
            "Look, that's why there's rules, understand? So that you _think_ before you break 'em."
  5. Привет.

    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

    --
    »Sie kochten heimlich mit Wasser und tranken öffentlich Wein.«
    1. 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

      --
      "Look, that's why there's rules, understand? So that you _think_ before you break 'em."
      1. Привет 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

        --
        »Sie kochten heimlich mit Wasser und tranken öffentlich Wein.«
        1. 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

          --
          "Look, that's why there's rules, understand? So that you _think_ before you break 'em."
    2. 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

      --
      Testbrowser Konqueror auch Webdesigner ohne Linux können darauf testen
      1. 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

        --
        Testbrowser Konqueror auch Webdesigner ohne Linux können darauf testen
      2. 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

        1. 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']    = "info@jeenaparadies.de";
           $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

          --
          Testbrowser Konqueror auch Webdesigner ohne Linux können darauf testen
          1. 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

      3. Привет 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

        --
        »Sie kochten heimlich mit Wasser und tranken öffentlich Wein.«
    3. 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

      1. hi,

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

        gruß,
        wahsaga

        --
        "Look, that's why there's rules, understand? So that you _think_ before you break 'em."
        1. 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.

      2. Привет 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

        --
        »Sie kochten heimlich mit Wasser und tranken öffentlich Wein.«
        1. 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

  6. 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

    --
    Testbrowser Konqueror auch Webdesigner ohne Linux können darauf testen
    1. 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

      --
      "Look, that's why there's rules, understand? So that you _think_ before you break 'em."
  7. 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

    1. Привет 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

      --
      »Sie kochten heimlich mit Wasser und tranken öffentlich Wein.«
    2. 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

      --
      Testbrowser Konqueror auch Webdesigner ohne Linux können darauf testen
  8. Привет.

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

    Дружба!
    Siechfred

    --
    »Sie kochten heimlich mit Wasser und tranken öffentlich Wein.«