Eine kleine Idee ist mir noch gekommen, welche aber eher für das "neue" gedacht.

Das Forum selbst gibt nur noch die blanken Daten per XML aus.
Das XML wird mit XSLT clientseitig im Browser gerendert.
(hier ein Beispiel für XML/XSLT: http://www.starcraft2.com)

In den Forumeinstellungen kann eine lokal gespeichertes XSLT angeben werden.
Das hatte ich bei einen Browsergame gesehen (http://www.travian.de). Die speichern normales CSS Design und Bilder auf der Platte.

Wer möchte kann sich dann ein komplett eigenes Design bauen. Wer das nicht will, kann nach wie vor die vorgegeben Designs vom Forum nuten.

Vorteile die ich sehe:
- XML Daten lassen sich ggf. weiterverarbeiten in einen Offlinereader
- nächster logischer Schritt nach Newsfeeds (RDF)
- evtl. weniger Datenvolumen welches übertragen wird.
- ein mögliches eigenes Design
- weniger Serverlast (CPU), da die Renderingfunktion wegfällt.

Der Server rendert das Forum?
Ich war immer der Meinung das der den HTML-Quellcode an meinen Browser schickt und der dieses interpretiert

Zitat von generic:

Vorteile die ich sehe:
- weniger Serverlast (CPU), da die Renderingfunktion wegfällt.

Hi,
an sich finde ich die Idee zwar auch nett, aber der Punkt ist imho falsch. Das Rendering findet schon jetzt auf Seite des Client statt! Der Browser bekommt eine Datei und rendert diese.
Serverseitig würde ich sagen (weiß es aber natürlich nicht) werden ohnehin nur Templates mit Daten aus der DB gefüllt. Somit dürfte die Serverlast sich kaum ändern.

Gruß Der Unwissende

Ich glaube, generic meint mit "Rendering" das gleichnamige Konzept aus ASP.NET, dabei wird nämlich ein Server-Control (so wie im Fall der Delphipraxis der Inhalt der Datenbank/Templates) nach HTML "gerendert", was dann an den Client geschickt wird. Das hat nichts mit der Darstellung im Browser zu tun und ist lediglich eine Überschneidung im Begriff "Rendering".

Edit: Vielleicht noch einen Kommentar zur Sache an sich:
Klingt eigentlich ganz toll, aber ist irgendwie auch riskant. Kleinere/ältere Browser lassen grüßen.

Ja. Aber ob ich die gleichen Daten nach (X)HTML oder in reines XML rendere - da ist kein wirklich großer Unterschied zwischen. Zumindest nicht in der Serverlast.

Zudem: die Beiträge sind schon in ihrer HTML-Darstellung gecached und werden nur aus der DB gelesen und sofort ausgeliefert. Die Serverlast ist also keinesfalls das Killerargument.

Die Sache mit der Darstellung sieht da schon anders aus. Ich persönlich finde ja, die DP ist u.a. wegen ihres Designs die DP. Wenn da dann jeder die DP bei sich so umdesignen könnte wie er wollte würde ein Teil von dem was die DP ausmacht nicht mehr allgemeingültig sein - und der Community eine Gemeinsamkeit fehlen. MeineMeinung(TM)

Auch das vBulletin hat ein eigenes Templating-System, welches dafür sorgt, dass ein vollständiger und gültiger Schwung an HTML-Gedöns an den Browser geschickt wird.

Der Template-Engine wäre das zwar egal, denn mit ein wenig Abstand betrachtet sind HTML und XML "nur" Text, der "ein wenig" strukturiert ist, aber der Weg über HTML kommt auch meiner Arbeitsweise näher, so dass ich auch diesen wieder verfolgen werde. Bedingt durch ausgefeilte Caching-Mechanismen, ist die durch das Template erzeugte Serverlast vergleichsweise gering.

Was den Offline-Reader angeht, der steht aber schon weiterhin in der Debatte, oder? Ich kann mich da düster an den DP-Experten erinnern

Sicher. Schnittstellen zu schaffen, ist nicht das Problem.
Aber das Projekt steht tendenziell eher weiter unten auf der Liste.

Hallo,

ich hatte diese Idee auch schon, habe mich allerdings bislang nicht getraut, diese (auf meiner Seite) umzusetzen. Interessantestes Argument für mich ist, dass nur noch sehr wenig "Gedöns" ausgeliefert wird, was sicher gut fürs Suchmaschinenranking ist. Allerdings hab ich Angst, dass diese Methode bei manchen (z.b. Leute, die mit älteren Browsern unterwegs sind) nicht funktioniert. Außerdem bin ich bei Google eh schon ziemlich gut platziert (Never change a running system ). Und sicherlich wird es einen Grund haben, wieso ich diese Technik erst einmal gesehen habe.

Es soll sogar Leute geben, welche noch mit dem alten 4'er Netscape surfen und kein Flashplugin haben. Wir sind im Jahr 2007 - man muss sich nicht gegen alles neue wehren. Du kannst gerne mit deinem Pferd noch durch die Steppe reiten, ich bevorzuge die Autobahn mit einen Sportwagen.

Thema Rendering:
Ja ich meine das Templaterendering also DB-Daten + Template = HTML
Das Rending zum Bildschrim macht bei beiden techniken natürlich der Browser.
(HTML + CSS + Grafiken = Anzeige oder XML + XSLT [+ CSS] [+ Grafiken] = Anzeige)

Offlinereader:
Man müsste keine neuen Schnittstellen schaffen, nur die Anmeldung/Session müsste halt durchgereicht werden.

Caching:
Das Caching kann man nach wie vor machen, einfach das XML speichern.

Design:
Klar, jedes Produkt hat sein design, aber man muss mit dem bereitgestellten nicht zufrieden sein.
Ich bin ein sehr einfacher Mensch. Viele zusätzliche Informationen kann man an unwichtigeren Stellen unterbringen. Mich persönlich stören z.B. die Footer und der Avatarbereich. Diese enthalten immer die gleichen unwichtigen Informationen. Wenn man Stammleser ist, kennt man die Sachen auswendig.

Ich würde mir den Avatarbereich einfach nach Rechts setzen. Footer, weg.
Kopf nur noch Datum und Verfasser.
Wichtig zu einen Beitrag ist doch nur Wer, Wann und Was.

Mir ist noch ein weiterer Vorteil eingefallen, dass XML mit dem XSLT lässt sich prima mit FOB in andere Formate wie z.B. PDF übertragen.