Brandauer: eigenes CMS - Datenstruktur

Hallo,

wie der Titel schon verrät, dreht sich die Frage um ein selbstgeschmiedetes CMS, welches sich in der ersten Entwicklungsphase befindet. Im Prinzip eine Art Webbaukasten. Warum das ganze? Weil der Kunde eine _sehr_ einfache Lösung für die Bearbeitung relativ simplen Contents haben will und ihm die gängigen Lösungen nicht gefallen haben, da zu kompliziert. Er will also mal einen Absatz verändern oder mal einen Listenpunkt hinzufügen, ohne Gefahr zu laufen, das Layout zu zerschiessen. Man kann davon halten, was man will.

Ich dachte mir, ich bau das gleich ein wenig aus und bastel mir ein System, welches Daten und Datenstruktur komplett trennt. An dieser Stelle möchte ich kurz meine Herangehensweise erläutern.

Oberste Prämisse ist die Datenreinheit. Es dürfen also in den Daten selbst (bis auf wenige Ausnahmen wie span, oder br im Fliesstext keine HTML-Elemente oder Attribute in den Daten vorliegen. Diese Daten werden als serialisierte Arrays oder als JSON in der DB gespeichert.

Es gibt ausserdem verschiedene Datenstrukturelemente, die die HTML-Struktur beschreiben und auf die die Daten später gemappt werden.

Ein kurzes Beispiel:

ein Datencontainer für ein p-Element _vor_ der Serialisierung:

  
$obje  
   'element_type' => "p",  
   'html_id' => "",  
   'html_class' => "standardAbsatz",  
   'html_style' => "color:red;",  
   'content' => "ein schöner Absatztext.",  
)  

gemappt werden diese Daten auf die folgende Struktur:

  
<p ID CLASS STYLE >  
{{content}}  
</p>  

Als HTML-Output würde dann, wie erwartet, folgendes zu sehen sein:

">  
<p class="standardAbsatz" style="color:red;">  
ein schöner Absatztext.</p>  

Konkret heisst das, jedes Datenelement wird serialisiert in einer DB gespeichert. Ein Absatz, eine Liste, ein Absatz mit Bild, etc.

Auf Backend-Seite sieht der Kunde für jedes Datenelement eine Formularentsprechung:
für obigen Absatz z.B. 3 Textfelder und eine Textarea (ip, class, style, content). Für eine  Liste ebenso 3 Textfelder und eine Textarea (ip, class, style, Listenpunkt pro Zeile). Wobei bei der Liste ganz nebenbei anzumerken ist, dass in der HTML-Struktur vermerkt wurde, dass jede Zeile aus der Textarea in einem Array-Element gespeichert werden soll. Nur falls sich jemand fragen sollte, was das soll.

Jetzt endlich die Frage:
Wie würdet ihr das machen im Falle einer Tabelle? Auf Kundenseite wäre eine Eingabemaske für eine Tabelle ebenfalls in einer Textarea denkbar, etwa so:

Filiale|Ort|Adresse
Maxfiliale|München|Musterstrasse
Testfiliale|München|Teststrasse
Musterfiliale|Frankfurt|Wurststrasse

(diese Daten werden in einen mehrdimensionalen Array gepackt und serialisiert, später beim Betrachten der Website wie oben beschrieben auf die entsprechenden Datenstrukturen gemappt)

Ist das sinnvoll? Ist sowas einem DAU zumutbar? (Über den Separator kann man streiten, ist nur ein Beispiel.) Oder wäre es besser, auch tabellarische Daten in einzelnen Inputfeldern auszuliefern? Oder ist die ganze Serialisierung Quatsch und ich sollte _ALLES_ in einzelnen DB-Feldern ablegen (das heisst für einen Absatz(!) hätte ich dann u.U. 4 Einträge in einer DB )?

  1. Lieber Brandauer,

    der Kunde will es einfach ("Super-DAU-sicher"), und Du machst daraus auf der anderen Seite eine solche Wissenschaft daraus, dass mir unterwegs der Sinn verloren ging.

    $obje  
    
    >    'element_type' => "p",  
    >    'html_id' => "",  
    >    'html_class' => "standardAbsatz",  
    >    'html_style' => "color:red;",  
    >    'content' => "ein schöner Absatztext.",  
    > )
    
    

    Mir will die Notwendigkeit für dieses Vorgehen nicht einleuchten. Mir drängt sich da irgendwie das Bild einer Hose und einer Beißzange auf...

    Als HTML-Output würde dann, wie erwartet, folgendes zu sehen sein:

    ">

    <p class="standardAbsatz" style="color:red;">
    ein schöner Absatztext.</p>

      
    Tja, wenn das der Output werden soll, warum muss das dann so zerlegt in der DB stehen? Warum nicht wirklich einfach und mit [WYSIWYG](http://tinymce.moxiecode.com)? Und was sollen die doppelten Anführungszeichen mit der schließenden spitzen Klammer vor dem Textabsatz?  
      
    
    > Konkret heisst das, jedes Datenelement wird serialisiert in einer DB gespeichert.  
      
    Wozu?  
      
    
    > Auf Backend-Seite sieht der Kunde für jedes Datenelement eine  
    > Formularentsprechung:  
      
    ??? Der Kunde wollte es doch "einfach"???  
      
    
    > für obigen Absatz z.B. 3 Textfelder und eine Textarea (ip, class, style, content).  
      
    Also ich finde in puncto Einfachheit ist WYSIWYG gerade in diesem Fall durch nichts zu ersetzen.  
      
    
    > Filiale|Ort|Adresse  
    > Maxfiliale|München|Musterstrasse[...]  
    > Ist das sinnvoll? Ist sowas einem DAU zumutbar?  
      
    Meiner Meinung nach "NEIN!". Wiki-Syntax in einem Formular um im Grunde RichText zu erzeugen... nerdiger geht's ja wohl kaum noch!  
      
    Nimm doch einen WYSIWYG-Editor (wie z.B. den TinyMCE) und speichere die HTML-Inhalte in Deiner DB. Den Rest erledigt das Backend.  
      
    Liebe Grüße,  
      
    Felix Riesterer.
    
    -- 
    ie:% br:> fl:| va:) ls:[ fo:) rl:° n4:? de:> ss:| ch:? js:) mo:} zu:)
    
    1. Hallo Felix,

      danke für deine Antwort. Ich musste gerade sehr lachen. Was ich hier vorstelle, ist nur die einfachste Variante, es gibt unzählige Datenstrukturen, die problemlos gemappt werden können.

      Mein Problem ist folgendes: diese Editoren produzieren HMTL-Code, das ist scheusslich. Ich mag es puristisch. Zum Beispiel möchte ich global mal eine Änderung haben, dann habe ich da HTML, vermutlich sogar CSS-Code im Text drin? URLs zum Beispiel (man nehme an, die Site soll auf eine andere Domäne verschoben werden, die Ordnerstruktur muss geändert werden, weil die Bilder jetzt nicht mehr unter images sondern unter bildschnipsel liegen sollen.

      der Kunde will es einfach ("Super-DAU-sicher"), und Du machst daraus auf der anderen Seite eine solche Wissenschaft daraus, dass mir unterwegs der Sinn verloren ging.

      $obje

      'element_type' => "p",
         'html_id' => "",
         'html_class' => "standardAbsatz",
         'html_style' => "color:red;",
         'content' => "ein schöner Absatztext.",
      )

      
      >   
      > Mir will die Notwendigkeit für dieses Vorgehen nicht einleuchten. Mir drängt sich da irgendwie das Bild einer Hose und einer Beißzange auf..  
        
        
      jeder Dateneintrag liegt in reiner Form vor.  
        
        
      
      > > Konkret heisst das, jedes Datenelement wird serialisiert in einer DB gespeichert.  
      >   
      > Wozu?  
        
      eben, wie gesagt in einzelnen Datenfeldern in einer Datenbank zum Beispiel.  
        
      
      >   
      > > Auf Backend-Seite sieht der Kunde für jedes Datenelement eine  
      > > Formularentsprechung:  
      >   
      > ??? Der Kunde wollte es doch "einfach"???  
        
      Ist das nicht einfach?  
        
      
      > > für obigen Absatz z.B. 3 Textfelder und eine Textarea (ip, class, style, content).  
      >   
      > Also ich finde in puncto Einfachheit ist WYSIWYG gerade in diesem Fall durch nichts zu ersetzen.  
        
      hmmm, wie gesagt, unreine Daten. Gefällt mir nicht.  
        
      
      > > Filiale|Ort|Adresse  
      > > Maxfiliale|München|Musterstrasse[...]  
      > > Ist das sinnvoll? Ist sowas einem DAU zumutbar?  
      >   
      > Meiner Meinung nach "NEIN!". Wiki-Syntax in einem Formular um im Grunde RichText zu erzeugen... nerdiger geht's ja wohl kaum noch!  
        
      \*lach\*  
        
      Danke für Feedback!  
      Brandauer  
      
      
  2. wie der Titel schon verrät, dreht sich die Frage um ein selbstgeschmiedetes CMS, welches sich in der ersten Entwicklungsphase befindet. Im Prinzip eine Art Webbaukasten. Warum das ganze? Weil der Kunde eine _sehr_ einfache Lösung für die Bearbeitung relativ simplen Contents haben will und ihm die gängigen Lösungen nicht gefallen haben, da zu kompliziert.

    Stopp: eigenes CMS basteln, wenn der Kunde bereits auf das Ergebnis wartet... das ist definitiv zu spät.

    Du willst etwas gut erprobtes ausliefern. ansonsten wird ein Kunde mit eigenen Mitteln/Editoren und einer Dokumentation aller CSS Klassen besser bedient sein.

    mfg Beat

    --
    ><o(((°>           ><o(((°>
       <°)))o><                     ><o(((°>o
    Der Valigator leibt diese Fische
    1. Hallo Beat,

      kein Problem, der Kunde hat _sehr_ lange Zeit. Momentan kann er schon seine Inhalte mit einem Editor verändern.

  3. Moin!

    Jetzt endlich die Frage:
    Wie würdet ihr das machen im Falle einer Tabelle? Auf Kundenseite wäre eine Eingabemaske für eine Tabelle ebenfalls in einer Textarea denkbar, etwa so:

    Filiale|Ort|Adresse
    Maxfiliale|München|Musterstrasse
    Testfiliale|München|Teststrasse
    Musterfiliale|Frankfurt|Wurststrasse

    Du erwartest von Deinem Kunde nicht, dass er einen WYSIWYG-Editor wie TinyMCE oder CKeditor bedienen kann. Aber CSV-Daten soll er von Hand eingeben ... (Kommentar: "Ist alles ganz logisch, aber was ist eigentlich in den Zigaretten die hier geraucht werden?")

    Ich frage mich gerade wie es erst wird wenn er Seiten anlegen soll... und was machst Du eigentlich mit Inline-Elementen wie z.B. Links in Deinem schönen Absatz?

    $obje
       'element_type' => "p",
       'html_id' => "",
       'html_class' => "standardAbsatz",
       'html_style' => "color:red;",
       'content' => "ein <a href="begrifferklarung.php?q=schöner">schöner</a> Absatztext.",
    )

    Dann müsstest Du 'content' in 3 Kind-Objekte auflösen (Text vor dem Link, Link+Text, Text nach dem Link) und diese auch verwalten. Ich vermute, Dein Kunde hat sehr viel "Spaß" dabei, das zu ändern ...

    Möglicherweise willst Du Dir mal anschauen, wie das alles in TinyMCE oder CKeditor oder CK-Editor realisert ist und (auch aus der Größe des Projektes) Rückschlüsse auf Dein Vorhaben ziehen - oder Deinem Kunde mal einen der beiden Editoren vorführen.

    MFFG (Mit freundlich- friedfertigem Grinsen)

    fastix

    1. Morgen Fastix,

      Du erwartest von Deinem Kunde nicht, dass er einen WYSIWYG-Editor wie TinyMCE oder CKeditor bedienen kann. Aber CSV-Daten soll er von Hand eingeben ... (Kommentar: "Ist alles ganz logisch, aber was ist eigentlich in den Zigaretten die hier geraucht werden?")

      Nehmen wir mal folgenden Fall:
      der Kunde will eine Liste pflegen, die eine relativ komplexe Struktur hat, zb. ein Bild, mit rechts davon ein wenig Text und nochmals rechts davon eine kleine tabellarische Abbildung von Produktwerten. Darunter dann gesamt in der Zeile noch ein Beschreibungstext und ein Link zu einer Detailseite.

      Mir will doch keiner erzählen, dass sowas in TincMC ohne MASSIVE Frustration machbar wäre? Ich kenne das von Wordpress.... frustrierend. Ohne HTML-Kenntnisse kommt da doch kaum mehr als ein Artikel raus, vielleicht noch ein Bild reingequetscht irgendwie. Von falschem Markup und nicht vorhandener Semantik ganz zu schweigen.

      Ergo müssen die Daten in einzelnen Datenbankfeldern liegen. Sicher, für einen stinknomalen Absatz braucht man nicht so einen Aufwand betreiben. Allerding, wenn ich schon dabei bin, kann ich das gleich für alle Elemente machen.

      Ich frage mich gerade wie es erst wird wenn er Seiten anlegen soll... und was machst Du eigentlich mit Inline-Elementen wie z.B. Links in Deinem schönen Absatz?

      $obje
         'element_type' => "p",
         'html_id' => "",
         'html_class' => "standardAbsatz",
         'html_style' => "color:red;",
         'content' => "ein <a href="begrifferklarung.php?q=schöner">schöner</a> Absatztext.",
      )

      Mit den Inline-Elementen habe ich auch die ganze Nacht gegrübelt. Wie weit will man gehen? Mir gefällt dieses Inline-Element überhaupt nicht. Andererseits alles in Kind-Objekte aufzudröseln... ?

      Dann müsstest Du 'content' in 3 Kind-Objekte auflösen (Text vor dem Link, Link+Text, Text nach dem Link) und diese auch verwalten. Ich vermute, Dein Kunde hat sehr viel "Spaß" dabei, das zu ändern ...

      Die Frage, welcher Kunde kann schon selbstständig einen vernünfigten Hyperlink anlegen, stelle ich mir oft.

      Möglicherweise willst Du Dir mal anschauen, wie das alles in TinyMCE oder CKeditor oder CK-Editor realisert ist und (auch aus der Größe des Projektes) Rückschlüsse auf Dein Vorhaben ziehen - oder Deinem Kunde mal einen der beiden Editoren vorführen.

      ix

      Ist ja nicht so, dass ich sowas nicht kenne. Für unsereins ideal, für Kunden (bei komplexeren Geschichten) frustrierend.

      1. Moin!

        Nehmen wir mal folgenden Fall:
        der Kunde will eine Liste pflegen, die eine relativ komplexe Struktur hat, zb. ein Bild, mit rechts davon ein wenig Text und nochmals rechts davon eine kleine tabellarische Abbildung von Produktwerten. Darunter dann gesamt in der Zeile noch ein Beschreibungstext

        Mein Gott: das ist nicht kompliziert, das kennt man doch aus jedem Webshop.

        Du willst die Daten dort abgreifen, wo diese "Detailseite" erzeugt wird:

        und ein Link zu einer Detailseite.

        Mach Dir also Gedanken um eine möglichst automatisch abfragbare Datenquelle, die Struktur der Ausgabe und dann sollte der Weg zur Lösung der Frage nach der Datenhaltung einfach sein.

        MFFG (Mit freundlich- friedfertigem Grinsen)

        fastix

        1. Hi,

          Nehmen wir mal folgenden Fall:
          der Kunde will eine Liste pflegen, die eine relativ komplexe Struktur hat, zb. ein Bild, mit rechts davon ein wenig Text und nochmals rechts davon eine kleine tabellarische Abbildung von Produktwerten. Darunter dann gesamt in der Zeile noch ein Beschreibungstext

          Mein Gott: das ist nicht kompliziert, das kennt man doch aus jedem Webshop.

          Nehmen wir an, es gibt keine Detailseite, das war ein Beispiel. Nehmen wir an, es existiert nur diese Liste.

          Du willst die Daten dort abgreifen, wo diese "Detailseite" erzeugt wird:

          und ein Link zu einer Detailseite.

          Mach Dir also Gedanken um eine möglichst automatisch abfragbare Datenquelle, die Struktur der Ausgabe und dann sollte der Weg zur Lösung der Frage nach der Datenhaltung einfach sein.

          das ist schon klar. Wenn es sich um einen Produktkatalog handelt, trägt man die Daten natürlich nicht doppelt -erst in Liste, dann in Detaiinformation- ein. Wir reden hier nicht über die Basics.

          1. Moin!

            Nehmen wir an, es gibt keine Detailseite, das war ein Beispiel. Nehmen wir an, es existiert nur diese Liste.

            Es ist unmöglich ein unendlich flexibles System bauen, welches dann auch noch einfach zu bedienen  ist: (nicht nur) Typo3 scheitert grandios an diesem Streben nach der eierlegenden Wollmilchsau.

            Also: Entweder ist Dein System einfach zu bedienen oder absolut universell. Gibt es jetzt einen ganz konkreten Grundaufbau oder aber nicht? Im erste Fall baue etwas, was dem folgt - im zweiten Fall biete dem Kunde an die Seiten schön einzeln zu fertigen.

            MFFG (Mit freundlich- friedfertigem Grinsen)

            fastix

            1. Hi,

              Es ist unmöglich ein unendlich flexibles System bauen, welches dann auch noch einfach zu bedienen  ist: (nicht nur) Typo3 scheitert grandios an diesem Streben nach der eierlegenden Wollmilchsau.

              In der Tat. Der Unterschied zu Typo3 besteht aber darin, dass mein System für den Kunden extra angepasst wird. Damit ich aber nicht für jeden Kunden irgendwelche Funktionen schreiben muss, gibt es dieses Datenstruktursystem.

              Ich lege eine neue Datenstruktur an, und diese kann dann gemappt werden.
              Im simpelsten Fall ein Absatz, im kompliziertem Fall eine ganze Page mit Widgets und komplexen, erweiterbarem Layout. Nur: alle diese Daten liegen in reiner Form vor und sind  (bis auf die paar inline-Beispiele) nicht mit Markup zugemüllt.

              Also: Entweder ist Dein System einfach zu bedienen oder absolut universell. Gibt es jetzt einen ganz konkreten Grundaufbau oder aber nicht?

              Einfach zu bedienen, pro Kunde konkreter Grundaufbau. Egal, mir ging es vor allem um die Tabelle. Da könnte ich mir durchaus eine Textarea mit Editor vorstellen... nur: wieder Markup in den Daten!

        2. Mach Dir also Gedanken um eine möglichst automatisch abfragbare Datenquelle, die Struktur der Ausgabe und dann sollte der Weg zur Lösung der Frage nach der Datenhaltung einfach sein.

          Im Prinzip unterstütz du mich aber in meinem Ansinnen. Datenhaltung, automatisch abfragbare Datenquelle, nicht wilde Datenformatierung in einem Editor.

          Nein, ein Editor kommt nicht in Frage, ausser für ein Element welches sich custom_HTML-Element nennt. Dort _darf_ HTML-Quellcode jeglicher Art rein.

          1. Moin!

            Im Prinzip unterstütz du mich aber in meinem Ansinnen.

            Nachdem Du konkreter geworden bist.

            Nein, ein Editor kommt nicht in Frage, ausser für ein Element welches sich custom_HTML-Element nennt. Dort _darf_ HTML-Quellcode jeglicher Art rein.

            Also der freie Text rechts vom Bild und die "Zeile" mit dem Beschreibungstext.

            Für die Tabelle lassen sich sicherlich eine Anzahl Inputs für Parameter-Wert-Paare anbieten. Die kann in der Eingabemaske man auch mit Javascript um eine Zeile ggf. sogar Spalte erweitern. Aber selbst dafür kann man z.B. den CK-Editor verwenden, dessen Symbolleiste ist nämlich 1. konfigurierbar und man kann ihm auch beim Erstaufruf des Items eine leere Tabelle unterschieben.

            MFFG (Mit freundlich- friedfertigem Grinsen)

            fastix

            1. Hi Fastix,

              Für die Tabelle lassen sich sicherlich eine Anzahl Inputs für Parameter-Wert-Paare anbieten. Die kann in der Eingabemaske man auch mit Javascript um eine Zeile ggf. sogar Spalte erweitern. Aber selbst dafür kann man z.B. den CK-Editor verwenden, dessen Symbolleiste ist nämlich 1. konfigurierbar und man kann ihm auch beim Erstaufruf des Items eine leere Tabelle unterschieben.

              Stimmt schon, aber wäre es nicht ein Gefummel? Wäre es nicht sinnvoller, eine Eingabeseite zu haben, die konkret nur die Liste um ein Feld erweitert? Alle Formatierungen, Zeile unterschieben, etc., fallen weg, der Kunde gibt nur stur pure Daten ein und hat semantisch und markup-technisch das allerbeste Ergebnis.

  4. moin,

    Oberste Prämisse ist die Datenreinheit. Es dürfen also in den Daten selbst (bis auf wenige Ausnahmen wie span, oder br im Fliesstext keine HTML-Elemente oder Attribute in den Daten vorliegen. Diese Daten werden als serialisierte Arrays oder als JSON in der DB gespeichert.

    Serialisiert ja, JSON nein, Letzteres ist zwar für die eigene bildliche Vorstellung einer Datenhaltung und ~Strukturierung hilfreich, praktisch jedoch viel zu langsam. Diese Frage stellt sich umso mehr, je feiner Du die Abstraktion einer Seite machst, also die Zerlegung in Komponenten.

    Du kannst an die Performance Zugeständnisse machen, wenn der Content geschrieben wird (Management), nicht jedoch bei der Auslieferung (User Request). Insofern spricht überhaupt nichts dagegen, wenn in der Datenhaltung eine Seite bereits zum Teil zusammengebaut vorliegt, z.B. in Teilen als Head, Body und Footer. Konkreter Fall: Ein Body beeinhaltet eine Tabelle oder eine verschachtelte <ul>, o.a. Inhalte, die mit einem aufwändigen Serverprozess erzeugt werden. Solche Prozesse sind im Management besser aufgehoben.

    In meiner Praxis abstrahiere ich in Sachen Trennung nur die Attribute vom Body. Attribute im Sinne eines CMS sind z.b. title, meta-descr, author, last-modified usw. In Perl sieht eine Datenstruktur dann so aus:

      
    $obj = {  
      title   => text/plain,  
      author  => text/plain,  
      body    => text/html,  
    };  
    
    

    D.h., Du hast in einem Objekt mehrere Content-Types, jedoch alles immerhin noch Text. Wenn Du das noch weiter abstrahieren willst, bekommst Du auch image/gif u.a. und da wirds mit der Datenhaltung schwierig ;-)

    Und selbstverständlich kann eine Seite auch schon fix und fertig zusammengebaut auf dem Server liegen, z.b. als "datei.html".

    Hotti

    1. Serialisiert ja, JSON nein, Letzteres ist zwar für die eigene bildliche Vorstellung einer Datenhaltung und ~Strukturierung hilfreich, praktisch jedoch viel zu langsam. Diese Frage stellt sich umso mehr, je feiner Du die Abstraktion einer Seite machst, also die Zerlegung in Komponenten.

      Du kannst an die Performance Zugeständnisse machen, wenn der Content geschrieben wird (Management), nicht jedoch bei der Auslieferung (User Request).

      Naja, im Grunde spricht ja wenig dagegen beides zu machen, also eine Art "Cache"-Funktion. Fürs Backend gibt es hübsch zerlegte Daten, die man praktisch manipulieren kann und wenn man die verändert wird gleichzeitig eine HTML-Struktur erstellt, die aber niemals zurück gerechnet wird und bei Bedarf auch einfach zerstört werden kann (um sie neu anzulegen).
      Wie dynamisch man sowas macht ist ja extrem variabel und kann von "Cache es beim Speichern" bis "cache es beim ersten Abruf" oder gar "cache es, wenn du gerade Zeit (idle) hast" gehen.
      Aus dem Bauch heraus erscheint mir zweiteres am sinnvollsten, zzgl. einer Versions-Kontrolle. Also bei Aufruf:
      Prüfen ob eine gecachte Version existiert
      Prüfen ob irgendwelche Daten, die diese Version manipulieren (Inhalte, Templates... mglw. inline-JS oder so) jünger sind als die im Cache angelegte Version.
      ggf. neu cachen
      und ab dafür.

      So verteilt man die Aktualisierung der Daten wenn zentrale Strukturen verändert werden imho ganz gut. Wenn ich so ein Template ändere, welches Einfluss auf X Datensätze hat muss ich eine Menge Zeug ersetzen. Da erscheint es praktischer wenn das nach und nach passiert beim Abruf. Zumal u.U. es sogar Inhalte geben mag, die eine "Zwischenversion" komplett überspringen, weil sie in Template-Version 2 (von 3) nie aufgerufen wurden. Ist ja auch nicht nötig, dass diese zwischendurch als HTML erstellt werden.

      Typisches Gedankenbeispiel: Man verändert ein Template, testet es und ändert es nochmal, weil man einen Fehler gemacht hat/unzufrieden ist. Da wäre es ja Quatsch, dass beim Zwischenschritt alle Daten umgerechnet werden.

      Und unterm Strich ist da noch die Last-Frage.
      Wenn das Frontend eh von maximal zwei Benutzern gleichzeitig belastet wird und die Nutzdaten pro Seite typischerweise wenige sind kann man im Grund doch auch dynamisch die Inhalte erzeugen.
      Ich stelle mir gerade die Website von Handwerksmeister Udo vor, auf dessen Page sich zweimal am Tag jemand verirrt und jeden zweiten Tag schaut sich jemand auch mehr als eine Seite an. Wenn die Generierung da eine halbe oder gar ganze Sekunde dauert ist das verkraftbar (zzgl. der Übertragungszeit selbstredend). Wenn man natürlich eine Seite hat, die ständig unter Last steht und da surfen im Schnitt hundert und zu Stoßzeiten dreihundert Leute drauf rum, dann ist das sicher nicht praktikabel (bzw. man braucht 'ne echte Wumpe als Server-Hardware und einen Webserver, der Multithreads beherrscht).

      --
      sh:( fo:| ch:? rl:( br:& n4:& ie:{ mo:} va:) de:µ_de:] zu:) fl:( ss:| ls:[ js:(
      1. moin,

        .. Wenn man natürlich eine Seite hat, die ständig unter Last steht und da surfen im Schnitt hundert und zu Stoßzeiten dreihundert Leute drauf rum, dann ist das sicher nicht praktikabel (bzw. man braucht 'ne echte Wumpe als Server-Hardware und einen Webserver, der Multithreads beherrscht).

        Jeder Request ein CGI-Prozess? Meine Optimierung ist die Trennung der Attribute vom Content(Body) wie folgt: Mit dem Request wurden zunächst die Attribute eingelesen und dabei festgestellt, ob es den angeforderten URL überhaupt gibt. Erst dann wird der Body in den RAM gelesen und die Seite ausgeliefert. Wenn es ein CGI-Prozess denn sein muss, den Cache des UA ansprechen mit Last-Modified oder Etag. Ich hab schon viele Seiten gesehen, die hahm sich zwar Mühe gegeben, den QUERY_STRING zu kaschieren, jedoch die Cache Frage (Status 304) total außer acht gelassen.

        Am Ende ist es jedoch besser, die Datei liegt physikalisch vor und der Webserver liefert die aus, ohne einen CGI-Prozess zu starten. Fürs Management bedeutet das: Schreibrechte ab DOCUMENT_ROOT, dafür gibt es SuExec.

        In beiden Fällen wird bei einer Änderung der Inhalte sowieso ein Update von Last-Modified (oder Etag) fällig, egal ob das beim Request dann der Webserver aus dem Dateidatum ermittelt oder ein CGI-Prozess als Seitenattribut aus einer DB.

        Bei Seiten mit 1000 Requests am Tag auf Last-Modified zu verzichten, ist tödlich.

        Hotti

        --
        Wenn der Kommentar nicht zum Code passt, kann auch der Code falsch sein.
        1. Am Ende ist es jedoch besser, die Datei liegt physikalisch vor und der Webserver liefert die aus, ohne einen CGI-Prozess zu starten. Fürs Management bedeutet das: Schreibrechte ab DOCUMENT_ROOT, dafür gibt es SuExec.

          Ja(!)
          Aber bei recht zentralen Änderungen (die also viele Dokumente betreffen) sehe ich einfach einfach ein Last-Problem, weil zumindest viele Dateien gelöscht, wenn nicht sogar neu generiert werden müssen und diesen Vorgang wollte ich verteilen.
          Aber wenn ich ehrlich bin: Bei der oben angesprochenen Handwerksmeister-Seite gibt es eh keine 1000 Dokumente, sondern eher 20 statische Seiten und wenn die auf einen Rutsch geändert werden ist das auch nichts wildes, haste Recht!

          --
          sh:( fo:| ch:? rl:( br:& n4:& ie:{ mo:} va:) de:µ_de:] zu:) fl:( ss:| ls:[ js:(
          1. Moin,

            Aber wenn ich ehrlich bin: Bei der oben angesprochenen Handwerksmeister-Seite gibt es eh keine 1000 Dokumente, sondern eher 20 statische Seiten und wenn die auf einen Rutsch geändert werden ist das auch nichts wildes, haste Recht!

            Das ist auch bei 200 oder mehr Dateien nüschd Wildes, die über ein neues Template zu ziehen oder anderweitig umzuschreiben. Was sein muss, muss sein und wie gesagt, es ist evntl. geschickter, den Server beim Management ein bischen zu stressen, als dies bei jedem Request zu tun.

            Hotti

            --
            Bulle: Wie heißen Sie!?
            Nutte: Przbilla-Kaspzic
            Bulle: Wie schreibt sich das denn!!??
            Nutte: Mit Bindestrich!
    2. Tag Hotti,

      Serialisiert ja, JSON nein, Letzteres ist zwar für die eigene bildliche Vorstellung einer Datenhaltung und ~Strukturierung hilfreich, praktisch jedoch viel zu langsam. Diese Frage stellt sich umso mehr, je feiner Du die Abstraktion einer Seite machst, also die Zerlegung in Komponenten.

      ich tendiere sowieso zur Serialisierung bzw. liegt auch schon so vor. JSON dachte ich nur als Austauschformat.

      In meiner Praxis abstrahiere ich in Sachen Trennung nur die Attribute vom Body. Attribute im Sinne eines CMS sind z.b. title, meta-descr, author, last-modified usw. In Perl sieht eine Datenstruktur dann so aus:

      $obj = {
        title   => text/plain,
        author  => text/plain,
        body    => text/html,
      };

      
      >   
        
      Das heisst, der Body wird bei dir in der DB als HTML gespeichert? Wie sieht es mit Redundanzen aus? Benutzt du ein Template-System?  
        
        
      
      >   
      > Und selbstverständlich kann eine Seite auch schon fix und fertig zusammengebaut auf dem Server liegen, z.b. als "datei.html".  
      >   
        
      Caching steht schon. Das heisst, nur wenn etwas geändert wird, wird das gecachte Dokument gelöscht und on Demand eimalig neu geschrieben.  
        
      
      
  5. Jetzt endlich die Frage:
    Wie würdet ihr das machen im Falle einer Tabelle? Auf Kundenseite wäre eine Eingabemaske für eine Tabelle ebenfalls in einer Textarea denkbar, etwa so:

    Filiale|Ort|Adresse
    Maxfiliale|München|Musterstrasse
    Testfiliale|München|Teststrasse
    Musterfiliale|Frankfurt|Wurststrasse

    (diese Daten werden in einen mehrdimensionalen Array gepackt und serialisiert, später beim Betrachten der Website wie oben beschrieben auf die entsprechenden Datenstrukturen gemappt)

    Ist das sinnvoll? Ist sowas einem DAU zumutbar? (Über den Separator kann man streiten, ist nur ein Beispiel.) Oder wäre es besser, auch tabellarische Daten in einzelnen Inputfeldern auszuliefern? Oder ist die ganze Serialisierung Quatsch und ich sollte _ALLES_ in einzelnen DB-Feldern ablegen (das heisst für einen Absatz(!) hätte ich dann u.U. 4 Einträge in einer DB )?

    Um DAU-sicher zu arbeiten musst du das Verhalten von Tabellenkalkulationen nachahmen.
    Ich fand die Methode von Typo3 nicht schlecht (und das ist das einzige CMS, welches ich aus Redaktioneller Sicht näher kenne). Die machen einfach beides, zunächst eine Textarea wie oben beschrieben mit dem | -Seperator (bzw. einstellbar) oder so eine Maske von input-Feldern, von denen einige als Kopf vorgesehen sind. Lässt sich IIRC auch hin und her schalten.
    Ich finde den Ansatz okay und für einigermaßen Computeraffine Menschen auch annehmbar, aber technopobe Leute, die Computer nur benutzen, weil sie müssen dürfte das zu komplex sein.

    Dann lieber mit "anderen Mitteln" eine Tabellenkalkulation simmulieren.
    Google-Docs macht das - wie ich finde recht geschickt - einfach mit HTML-Tabellen. Sie fangen Tastatureingaben ab und verändern daraufhin die HTML-Tabelle bzw. das CSS mit JavaScript.
    Ebenso denkbar sind Canvas+JavaScript, Flash, Silverlight und natürlich Java.
    Dabei halte ich Java für die simpelste Lösung, HTML+JS für die beste und Canvas+JS kam mir als erstes in den Sinn ^^
    Meine Empfehlung also: Die Maske sei eine HTML-Tabelle und alle relevanten Tastatur- und Maus-Eingaben werden abgefangen, so dass man mit Pfeiltasten/Enter durch die Tabelle navigieren kann und durch Zeicheneingabe einfach in das aktuelle Feld schreibt (typischerweise: überschreibt). Dabei würde ich mich echt an Google bzw. halt Tabellenkalkulationen orientieren und eben _nicht_ das aktuelle (quasi "markierte") Feld mit einem Input belegen, sondern in einem zentralen Input den Inhalt der aktuellen Zelle darstellen. (Dieses Input muss auch kein "echtes" sein, kann man aber imho machen).
    Jede Zelle bekommt noch ihren Style bzw. Klasse, wobei ich einfach nicht erlauben würde innerhalb einer Zelle unterschiedlich zu formatieren, das macht es unnötig komplex, im Gegenteil kann man die Formatierungen massiv einschränken, indem man erlaubt den Zellen Semantik zu geben: "Dies ist eine Kopfzelle/-zeile"; "Dies ist eine Ergebnis-Zelle/-Spalte" (...).
    Darüber hinaus kann man auch das teilweise automatisieren (Daten-Art feststellen: Zahl, Datum, Zeit, Text...).
    Ob dein(e) Kunde(n) auch tatsächlich die _Kalkulation_ brauchen, also ob das rechnen können muss musst du selber wissen, aber so Sachen wie =HEUTE(); sind schon nützlich ^^
    Und wenn es fertig ist stell es bitte unter einer offenen Lizenz ins Netz :D

    Naja oder du nimmst was fertiges.

    --
    sh:( fo:| ch:? rl:( br:& n4:& ie:{ mo:} va:) de:µ_de:] zu:) fl:( ss:| ls:[ js:(
    1. Hi,

      Um DAU-sicher zu arbeiten musst du das Verhalten von Tabellenkalkulationen nachahmen.
      Ich fand die Methode von Typo3 nicht schlecht (und das ist das einzige CMS, welches ich aus Redaktioneller Sicht näher kenne). Die machen einfach beides, zunächst eine Textarea wie oben beschrieben mit dem | -Seperator (bzw. einstellbar) oder so eine Maske von input-Feldern, von denen einige als Kopf vorgesehen sind. Lässt sich IIRC auch hin und her schalten.
      Ich finde den Ansatz okay und für einigermaßen Computeraffine Menschen auch annehmbar, aber technopobe Leute, die Computer nur benutzen, weil sie müssen dürfte das zu komplex sein.

      Eine gute Sache! Allerdings wird es sich nicht um eine Tabellenkalkulation handeln. Das ist mir jetzt erstmal zu aufwändig. Mir geht es eher um Tabellendaten, die Layout-Charakter haben. Wie beschriebene Filialtabelle. Wer rechnen will, muss dann eine spezielle Lösung bestellen.

      Dumme Frage: aus dem Canvas-Element heraus sind die Daten nicht kopierbar? Ich habe mit diesem Element noch keine Erfahrung.

      Und wenn es fertig ist stell es bitte unter einer offenen Lizenz ins Netz :D

      mach ich ;)

  6. Hello,

    was mich bei diesen ganzen "selbstgemachten" oder auch "fertigen" CMS immer wundert, ist dass sie oft eigentlich gar nicht den Content managen, sondern nur dessen Darstellung.

    Unter einem Content-Management-System, speziell für Firmendarstellungen und -kontaktseiten, stelle ich mir vor, dass sie die Bearbeiter wirklich auch beim Content und dessen Bedeutung unterstützen:

    Wenn Lieschen Müller in der Firma eine neue Position einnimmt, muss das überall dort, wo das Objekt Lieschen Müller auftaucht, auch Berücksichtigung finden. Das Objekt muss dort also entfernt, ausgetauscht oder verändert werden. Genauso ist es, wenn sich eine Telefonnummer ändert, eine neue Abteilung installiert oder eine andere wegrationalisiert wird... Alle Bezüge dazu müssen aktualisiert werden.

    Ein CMS sollte mMn also ein "Web im Web" darstellen, dass auf die Belange des Anwenders zugeschnitten werden kann und das ihn bei der Verwaltung seiner Strukturen untersützt, indem es ein möglichst genaues Abbild davon verwendet. Was davon dann nach außen dargestellt werden soll, muss ggf. auch noch durch eine Transformation laufen...

    Wie chaotisch eine Abblidung durch wachsende Fehleranzahl werden kann, sehen wir an Google. Millionen von Links verweisen nicht mehr auf den Inhalt, den man im ersten Augenblick annehmen sollte.

    Liebe Grüße aus dem schönen Oberharz

    Tom vom Berg

    --
     ☻_
    /▌
    / \ Nur selber lernen macht schlau
    http://bergpost.annerschbarrich.de
    1. Hello,

      was mich bei diesen ganzen "selbstgemachten" oder auch "fertigen" CMS immer wundert, ist dass sie oft eigentlich gar nicht den Content managen, sondern nur dessen Darstellung.

      Richtig, genau das habe ich in meinem Konzept auch vorgesehen. Das ist auch das, was mich an Drupal oder solchen fertigen, ultimativen Systemen stört. Mein System und und dessen Datenstrukturen müssen speziell eingerichtet werden.

      Z.b. gibt es Adressobjekte oder Produktobjekte, die eingebunden werden und nicht seitenspezifisch sind.

      Ein CMS sollte mMn also ein "Web im Web" darstellen, dass auf die Belange des Anwenders zugeschnitten werden kann und das ihn bei der Verwaltung seiner Strukturen untersützt, indem es ein möglichst genaues Abbild davon verwendet. Was davon dann nach außen dargestellt werden soll, muss ggf. auch noch durch eine Transformation laufen...

      Das ist eine gute Idee. Ich komm ja aus der Sparte Geoinformationssysteme, und da wird -zumindest dort wo ich arbeite- jede kleinste Informationseinheit getrennt abgelegt. Mir gefällt dieses *nur Darstellen* bei bestimmten CM-Systemen überhaupt nicht.

      Daten müssen meines Erachtens auswertbar sein. Mit Editoren generierte
      Daten, die Markup oder sonstigen Code beinhalten, ist das möglicherweise problematisch.

      Ausserdem muss jedes Element eine semantische Zuordnung haben. *Nur* ein loser Absatz ohne Zuordnung finde ich gruselig... Der Absatz muss zum Beispiel als einer übergeordneten Information zugehörig gemacht werden, z.B. Absatz 1 des Dokuments Firmenbeschreibung, eventuell mit einer kurzen Beschreibung des Absatzinhaltes. Natürlich sind dem Absatz noch weitere Informationen zugeordnet wie Erstellungsdatum, Ersteller, etc.

      Na gut, ob man so weit gehen muss....? Ich fände es schön.

    2. Unter einem Content-Management-System, speziell für Firmendarstellungen und -kontaktseiten, stelle ich mir vor, dass sie die Bearbeiter wirklich auch beim Content und dessen Bedeutung unterstützen:

      Wenn Lieschen Müller in der Firma eine neue Position einnimmt, muss das überall dort, wo das Objekt Lieschen Müller auftaucht, auch Berücksichtigung finden. Das Objekt muss dort also entfernt, ausgetauscht oder verändert werden. Genauso ist es, wenn sich eine Telefonnummer ändert, eine neue Abteilung installiert oder eine andere wegrationalisiert wird... Alle Bezüge dazu müssen aktualisiert werden.

      Wie gesagt kenne ich nur Typo3 von der Redakteur-Seite, aber dort ist das im Grunde so. Man kann für allen Scheiß Datensätze anlegen und mehrerorts "verknüpfen". Das Problem ist nur: Es macht kaum jemand!

      Ein Beispiel aus meiner Praxis:
      Wie benutzen Typo3 im Wesentlichen dazu Reviews (aber auch andere Artikel) zu publizieren.
      Zu einer Review gehören u.a. Informationen wie der Hersteller des Produkts (da es sich bei uns idR um Bücher handelt: Verlag). Diese Hersteller sind interessanterweise nicht sonderlich viele und so gibt es einfach einen Datentyp "Verlag" in dem der Name des Verlages und dessen URL hinterlegt sind. Der Review wird also ein Verlag zugeordnet. Ändert sich der Name des Verlags (bspw. durch Fussion oder er ändert die Geschäftsform) oder dessen URL, so kann das zentral geändert werden.
      Gleiches gilt für Bilder, ich pflege normalerweise das gleiche Cover in die Review sowie in die "News" dass eine Review erschienen ist. Man nehme an, ich bekomme das Cover in einer besseren Auflösung, dann tausche ich es aus und es ist in beiden Inhalten aktualisiert (okay, Typo ist da etwas zickig bei Bildern/Binärdaten, aber im Prinzip...).
      Es gibt noch ein paar kleinere Stellen wo das gemacht wird (z.B. ist die Produkt-Sprache ein eigener Datentyp, nur dass sich der wohl nie ändern wird).
      Darüber hinaus experimentieren wir ein wenig mit dem Einbinden eines Lizenztextes in Artikel (offene Lizenzen werden ja zuweilen aktualisiert und erlauben auch sich selbst zu aktualisieren), sowie Autoren (bei denen z.B. eine Mail-Adresse hinterlegt werden könnte, die sich ebenfalls ändern kann). Wie gesagt nur im experimentier-Stadium.

      Was ich sagen will: Das geht schon! Aber es macht keine Sau, weil es unbequem ist. Man muss ja erstmal den Datentyp definieren und den Redakteuren erklären, wie und wo sie ihn benutzen und neue Elemente des Typs anlegen und so fort. Und da ist es eben billig und einfach, den Namen und die Mail-Adresse einfach jedes Mal neu einzugeben... im Zweifel kann man es ja direkt auf der Datenbank suchen+ersetzen.
      Man kann den Herstellern der CMS hier imho nicht wirklich einen Vorwurf machen. Sicher könnte man es stärker forcieren, aber das Angebot ist da, man muss es nur nutzen (und man muss sich ein bisschen reinfuchsen und nicht nur das System installieren).

      --
      sh:( fo:| ch:? rl:( br:& n4:& ie:{ mo:} va:) de:µ_de:] zu:) fl:( ss:| ls:[ js:(
  7. Hi Brandauer!

    Auch wenn es vielleicht schon zu spät ist, solltest du dir Redaxo anschauen.
    Da hast du viele Möglichkeiten, eine Seite zu erstellen und kannst deinem Kunden mit Modulen eine einfache Inhaltseingabe ermöglichen.

    Redaxo ist zwar schlecht dokumentiert, hat aber eine freundliche Community und wenn du ein guter Programmierer bist, kommst du sicher schnell damit zurecht.

    MfG H☼psel

    --
    "It's amazing I won. I was running against peace, prosperity, and incumbency."
    George W. Bush speaking to Swedish Prime Minister unaware a live television camera was still rolling, June 14, 2001
    Selfcode: ie:% fl:( br:> va:) ls:& fo:) rl:? n4:& ss:| de:] js:| ch:? sh:( mo:) zu:)
    1. Hi Hopsel,

      Auch wenn es vielleicht schon zu spät ist, solltest du dir Redaxo anschauen.
      Da hast du viele Möglichkeiten, eine Seite zu erstellen und kannst deinem Kunden mit Modulen eine einfache Inhaltseingabe ermöglichen.

      Es ist nie zu spät! Ich arbeite ja hin und wieder mal mit anderen CM-Systemen wie WordPress, Drupal oder der einen oder anderen Shop-Software.

      Redaxo ist zwar schlecht dokumentiert, hat aber eine freundliche Community und wenn du ein guter Programmierer bist, kommst du sicher schnell damit zurecht.

      Ich habe schon davon gehört. Ich werde es mir mal angucken. Danke für den Tip! Mein CMS, bis das ausgereift ist (wenn überhaupt eines Tages), dauert sowieso noch einige Zeit. Bis dahin wäre eine Lösung, auch für andere Projekte, nicht schlecht.

      Brandauer