Ein Forum ganz in AJAX

[hotti]

Wollt' ich schon immer mal machen. Wer möchte, kann sich das mal hier anschauen.

MfG

[Chris2]

Hi.

Wollt' ich schon immer mal machen. Wer möchte, kann sich das mal hier anschauen.

Na, das ist ja der Wahnsinn!

G
Chris

[hotti]

Hi,

welcher Browser zeigt Dir denn die Fehlermeldungen in die Console? Mein FF 30.0.3 zeigt mir nix. Content-Length z.B. schickt der automatisch mit. Dein Browser übrigens auch, wie Dein Screenshot zeigt, sonst könntest Du die Nachricht nicht lesen ;)

[unknown]

Content-Length z.B. schickt der automatisch mit.

Und warum willst du das dann händisch setzen, wenn es der Browser schon automatisch macht?

[hotti]

Content-Length z.B. schickt der automatisch mit.
Und warum willst du das dann händisch setzen, wenn es der Browser schon automatisch macht?

Das sind Altlasten in meiner alib.js, muss ich mal bereinigen, das Teil ist uralt.

[M.]

Mahlzeit,

Das sind Altlasten in meiner alib.js, muss ich mal bereinigen, das Teil ist uralt.

Vielleicht solltest du das Rad mal ne erfinden. SCNR

[Rainer]

Grüß dich Hotti,

und wo downloaden? ;-)

Gruß Rainer

[hotti]

Grüß dich Hotti,

Dich auch :)

und wo downloaden? ;-)

Das Ding ist so einfach, das hasst Du an einem Abend programmiert ;)

Ne, im Ernst, Deine Frage nehme ich mir an. Jetzt lass das Teil mal ne Weile auf meiner Seite laufen, da kommt bestimmt noch was zusammen an Features- sowie Flame-Requests. So sind in meiner alib.js auch noch ein paar Altlasten drin, die in modernen Entwicklerwerkzeugen Fehler in die Console spucken.

Ansonsten hats mich selbst überrascht, wie affenartig schnell dieses Forum ist und ein Neuladen der Seite kannste Dir damit echt abgewöhnen ;)

MfG

[hotti]

hi,

und wo downloaden? ;-)

Jetzt gibts ersteinmal ein neues Feature Forum auf beliebigen Seiten

D.h., das Forum, weil AJAX, kann in jede beliebige Webseite eingebaut sein, vorne, hinten, oben, unten, rechts und links.

So sind bspw. themenbezogene Foren möglich, wo einfach in einen, dem Thema entsprechenden Artikel eingebaut sind und so sind Diskussionen eben einem bestimmten Thema zugeordnet.

Ein solches Forum wird einfach als Platzhalter ins HTML-Template eingebaut und das wars schon. Konfiguriert wird nur noch, je nach Data-Abstraction-Layer (DAL), der Name der Forumsdatei oder der Name der ForumsTabelle in der Datenbank. Der DAL ist selbstverständlich austauschbar, den habe ich auch auf meiner Site beschrieben.

MfG

[hotti]

hi again,

und wo downloaden? ;-)

Andere Variante (so langsam liebe ich das Teil *G):

Einfach auf der eigenen Seite einbinden, geht so:

  
<script src='/cgi-bin/forum_proxy.cgi?path=board.html'></script>  
<h3 id="main_index" style="cursor:pointer; padding-top:1em">  
    <span onClick="browse()">Forum Hauptindex: hier klicken! </span>  
</h3>  
  
<div id="tree_div"> </div>  
<div id="form_div"> </div>  

Optional dazu (damit wird das gleich aufgeklappt):

  
<script> browse(); </script>  

Voraussetzung: Dein Provider unterstützt Perl/CGI wg. dem Script forum_proxy.cgi

Dieses Script stelle ich auf Anfrage bereit, Tester willkommen. Das Proxy-Script reicht auch den Session-Cookie durch, so bleibt der Nickname in einer Browsersitzung stehen.

Die Performanze sieht gut aus, der Proxy ist sozusagen transparent :)

MfG

[Mitleser]

<script src='/cgi-bin/forum_proxy.cgi?path=board.html'></script>
Voraussetzung: Dein Provider unterstützt Perl/CGI wg. dem Script forum_proxy.cgi

Warum? Wenn Du eh ins DOM schreibst, kannst Du die SOP dann auch auch mittels JSONP/CORS umgehen und direkt <script src='//rolfrost.de/beepworld2.0?customer=Rainer'></script> fahren.

[hotti]

<script src='/cgi-bin/forum_proxy.cgi?path=board.html'></script>
Voraussetzung: Dein Provider unterstützt Perl/CGI wg. dem Script forum_proxy.cgi

Warum? Wenn Du eh ins DOM schreibst, kannst Du die SOP dann auch auch mittels JSONP/CORS umgehen und direkt <script src='//rolfrost.de/beepworld2.0?customer=Rainer'></script> fahren.

So einfach wie das möglicherweise funktioniert, ist es nicht, denn für Foren eines Mandanten (Kunden) gibt es eine Policy, konkret:

Ein Mandanten(Kunden)-Forum läuft in einer Session über das Framework. Hierbei greift mein eigens entwickeltes Verfahren zur Content-Negotiation. Für den Aufruf eines Kunden-Forum sind Benutzername/Passwort erforderlich, diese Credentials richte ich über ein Backend ein. Ein Kunde kann sein Forum über das Proxy-Script auf seiner eigenen Seite einbinden, in diesem Fall sind die Zugangsdaten im Proxy-Script hinterlegt, welches nur der Mandant besitzt und auf seinem Webserver installiert.

Selbstverständlich kann ein Kunde ein Forum auf seiner eigenen Seite auch mit einem Passwortschutz versehen (.htaccess, Authorization Basic). Für den in diesem Fall eingegebenen Namen des angemeldeten Benutzers ist der Proxy transparent, d.h., dieser Benutzername wird gleich als Nickname in das Forum durchgereicht.

Der Proxy ist transparent, d.h., die Benutzer kriegen das gar nicht mit, dass im Hintergrund eine Host-Session aufgebaut wird.

Ohne Proxy wird das alles nichts, mehr dazu auf meiner ProjektSeite

MfG

[Mitleser]

[...]

Ohne Proxy wird das alles nichts, mehr dazu auf meiner ProjektSeite

Ei dann mach _einen_ initialen, server2server Auth-Request (ob per Perl, PHP oder was auch immer sollte egal sein) und lass den Client danach _direkt_ mit Deinem Server kommunizieren. Alles über den Proxy zu schicken ist unnötiger Overhead.

[hotti]

Moin,

[...]

Ohne Proxy wird das alles nichts, mehr dazu auf meiner ProjektSeite

Ei dann mach _einen_ initialen, server2server Auth-Request (ob per Perl, PHP oder was auch immer sollte egal sein) und lass den Client danach _direkt_ mit Deinem Server kommunizieren. Alles über den Proxy zu schicken ist unnötiger Overhead.

Mag sein, dass Du die Architektur verstehst, aber Du verstehst den Sinn des Gateways nicht. Ich habe gestern ein Forum für einen Kunden in der Schweiz eingerichtet. Der Proxy ist der Komfort, welchen ich dem Kunden biete, er kann:

1. mit weniger Komfort das Forum direkt auf dem Host (rolfrost.de) benutzen, Nachteil: alle Benutzer müssen das Masterpasswort kennen zur Anmeldung auf dem Host
2. er nutzt das Forum komfortabel über eine eigene Seite mit Proxy-Anbindung auf seiner eigenen Domäne und nutzt dort seine eigene Benutzerverwaltung

Im Fall (2) ist der Proxy für die Benutzer transparent, die Benutzer müssen das Masterpasswort nicht kennen, das braucht nur der Gateway. Benutzer nutzen das Forum auf der Seite in der Schweiz und die Zugangsdaten die auf der schweizer Domäne hinterlegt sind. Forumbenutzer wissen nichts von einer Host-Anbindung (Transparent Proxy).

Sollte ein Benutzer selbst versuchen, über den in der Schweiz installierten Proxy auf das Forum zu kommen, braucht er die Zugangsdaten zum Proxy vom Provider in der Schweiz. Ein Zugang zum Forum direkt auf dem Host ist nur mit Masterpasswort möglich.

MfG

[Mitleser]

Mag sein, dass Du die Architektur verstehst, aber Du verstehst den Sinn des Gateways nicht. [...]

Ick gebe auf. Du hast für Dich offensichtlich die perfekte Lösung gefunden. Viel Erfolg damit!

[1UnitedPower]

Meine Damen und Herren, habe ich Ihre Aufmerksamkeit?

Wollt' ich schon immer mal machen. Wer möchte, kann sich das mal hier anschauen.

Verbesserungs-Vorschlag: Wenn ein Nutzer durch dein Forum navigiert sollte sich die Adresszeile respektive ändern. Dann könnte er auch die Browser-History nutzen, direkte Links zu den Beiträgen ließen sich teilen, und der Refresh-Button würde die Seite aktualisieren und nicht zur Foren-Hauptseite zurück springen.

[hotti]

Moin ;)

Verbesserungs-Vorschlag: Wenn ein Nutzer durch dein Forum navigiert sollte sich die Adresszeile respektive ändern. Dann könnte er auch die Browser-History nutzen, direkte Links zu den Beiträgen ließen sich teilen, und der Refresh-Button würde die Seite aktualisieren und nicht zur Foren-Hauptseite zurück springen.

Wer bei einer Single-Page-Application den Backbutton benutzt, möchte die Seite verlassen. Wer bei einer SPA den Reload-Button benutzt, macht im Prinzip nichts falsch. Wer jedoch bei einer SPA in der Adresszeile was Anderes erwartet, wenn andere Inhalte erscheinen, hat den Sinn einer SPA nicht verstanden.

Neues Feature: Gelesene Markierungen (mit store.js).

MfG

[dedlfix]

Tach!

Wer bei einer Single-Page-Application den Backbutton benutzt, möchte die Seite verlassen. Wer bei einer SPA den Reload-Button benutzt, macht im Prinzip nichts falsch. Wer jedoch bei einer SPA in der Adresszeile was Anderes erwartet, wenn andere Inhalte erscheinen, hat den Sinn einer SPA nicht verstanden.

Als Anwender ist es mir völlig egal, ob ich da eine herkömmliche Seitensammlung, eine SPA oder was ganz anderes vorgesetzt bekomme. Ich erwarte, dass die Funktion meiner Bedienelemente gegeben ist. Wer das als Anwendungsersteller anders macht, hat Anwenderfreundlichkeit nicht verstanden. Die (modernen) Browser sind auch so zuvorkommend, eine Funktionalität dafür bereitzustellen: https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Manipulating_the_browser_history.

dedlfix.

[Chris2]

Moin,

"Don't forget the back button in your single page app"

Wer bei einer Single-Page-Application den Backbutton benutzt, möchte die Seite verlassen.

Nein. Einem Nutzer ist es gaenzlich egal, ob es eine SPA, statische oder server-side generated HTML-Seiten sind.
Es liegt in der Aufgabe des verantwortungsbewussten Entwicklers dem User das zu erwartende Browserverhalten zu bieten.

Wer bei einer SPA den Reload-Button benutzt, macht im Prinzip nichts falsch.

Ein Reload einer URL soll genau den gleichen Inhalt liefern.

Wer jedoch bei einer SPA in der Adresszeile was Anderes erwartet, wenn andere Inhalte erscheinen, hat den Sinn einer SPA nicht verstanden.

Nein, DU hast den Sinn von SPAs nicht verstanden.
ALLE ernstzunehmenden SPA-Frameworks legen einen sehr starken Fokus auf Routing-Funktionalitaeten. Auch die gaengigen Search-Engines beruecksichtigen Fragment-Routes, siehe zb https://developers.google.com/webmasters/ajax-crawling/

Hier Links auf APIs und Dokus der bekannten SPA-Frameworks und deren Routing-Unterstuetzung:
Angular: fragment identifier, $routes
Meteor: iron-router
ember.js: Routing
backbone: history, microstates
knockout: knockback-navigators

Und, lieber Hotti, bitte ERST die Docs LESEN, und nicht wieder wild unreflektiert antworten.

G
Chris

[Tabellenkalk]

Hallo,

Ein Reload einer URL soll genau den gleichen Inhalt liefern.

Oder aktuelleren!

Gruß
Kalk

[Auge]

Hallo

Moin ;)

Verbesserungs-Vorschlag: Wenn ein Nutzer durch dein Forum navigiert sollte sich die Adresszeile respektive ändern. Dann könnte er auch die Browser-History nutzen, direkte Links zu den Beiträgen ließen sich teilen, und der Refresh-Button würde die Seite aktualisieren und nicht zur Foren-Hauptseite zurück springen.

Wer bei einer Single-Page-Application den Backbutton benutzt, möchte die Seite verlassen. Wer bei einer SPA den Reload-Button benutzt, macht im Prinzip nichts falsch.

Wer eine SPA im Browser benutzt, weiß im Normalfall nicht einmal, was eine SPA ist. Wer eine SPA im Browser benutzt, und nicht weiß, dass es eine ist, erwartet zurecht, dass die Bedienelemente seines Browsers das tun, was sie sollen.

Wer jedoch bei einer SPA in der Adresszeile was Anderes erwartet, wenn andere Inhalte erscheinen, hat den Sinn einer SPA nicht verstanden.

/* no comment */

Tschö, Auge

[Gunnar Bittersmann]

@@hotti:

nuqneH

Wer bei einer Single-Page-Application den Backbutton benutzt, möchte die Seite verlassen. Wer bei einer SPA den Reload-Button benutzt, macht im Prinzip nichts falsch. Wer jedoch bei einer SPA in der Adresszeile was Anderes erwartet, wenn andere Inhalte erscheinen, hat den Sinn einer SPA nicht verstanden.

Ach hotti, warum machst du aus allem, was du gut und ernst meinst, eine Lachnummer?

Qapla'

[M.]

Mahlzeit,

Wer bei einer Single-Page-Application den Backbutton benutzt, möchte die Seite verlassen. Wer bei einer SPA den Reload-Button benutzt, macht im Prinzip nichts falsch. Wer jedoch bei einer SPA in der Adresszeile was Anderes erwartet, wenn andere Inhalte erscheinen, hat den Sinn einer SPA nicht verstanden.

Nur mal so aus Interesse, wieviel % der Internetnutzer wissen, was eine SPA ist?
Ich würde schätze so 1-2% und da greife ich schon recht hoch.

[Gunnar Bittersmann]

@@M.:

nuqneH

Nur mal so aus Interesse, wieviel % der Internetnutzer wissen, was eine SPA ist?
Ich würde schätze so 1-2% und da greife ich schon recht hoch.

Sehr hoch. Zumal man es bei einer richtig gemachten SPA gar nicht unbedingt merkt, dass es eine solche ist, weil sie sich wie mehrere einzelne Webseiten verhält. Eben weil sich der URI in der Adressleiste mit jedem Zustand ändert, man Zustände bookmarken kann und der Back-Button funktioniert.

Qapla'

[Camping_RIDER]

Aloha ;)

Sehr hoch. Zumal man es bei einer richtig gemachten SPA gar nicht unbedingt merkt, dass es eine solche ist, weil sie sich wie mehrere einzelne Webseiten verhält. Eben weil sich der URI in der Adressleiste mit jedem Zustand ändert, man Zustände bookmarken kann und der Back-Button funktioniert.

Mal ganz naiv gefragt: Muss ich dazu wirklich die Browser-History manipulieren mit dem ganzen Rattenschwanz an Arbeit dahinter? Eigentlich müsste es doch reichen den Anchor in der URL zu manipulieren (also .../forum.html#thread1antwort3 oder so)... Schließlich kann ich so effektiv die url verändern und bookmark-bar machen ohne, dass der browser die seite neu lädt... auch refresh und back funktioniert dann. Auch rein "semantisch"/logisch wäre der anchor dafür nicht die schlechteste wahl...

Grüße,

RIDER

[dedlfix]

Tach!

Mal ganz naiv gefragt: Muss ich dazu wirklich die Browser-History manipulieren mit dem ganzen Rattenschwanz an Arbeit dahinter? Eigentlich müsste es doch reichen den Anchor in der URL zu manipulieren (also .../forum.html#thread1antwort3 oder so)...

Ändern der Adresszeile mit einem History-Eintrag und Austauschen ohne Eintrag ist beides nur ein einzelner Aufruf einer History-API-Funktion. Ob Anker oder nicht, ändert daran nichts.

Bei einem direkten Aufruf ohne Anker kann der Server sofort den richtigen Inhalt liefern, mit Anker muss man noch einen Ajax-Request nach dem eigentlichen Inhalt hinterherschicken

dedlfix.

[Camping_RIDER]

Aloha ;)

Bei einem direkten Aufruf ohne Anker kann der Server sofort den richtigen Inhalt liefern, mit Anker muss man noch einen Ajax-Request nach dem eigentlichen Inhalt hinterherschicken

Hmm, aber es ging ja um ein Forum ganz in AJAX?...

Überhaupt, dieser zusätzliche AJAX-Request entsteht ja so oder so nur ein einziges mal (nämlich beim erstmaligen Aufruf über Lesezeichen) jeder weitere Navigatinsschritt geht ja dann direkt über AJAX...

Außer ich hab was grundsätzlich missverstanden...

Grüße,

RIDER

[dedlfix]

Tach!

Bei einem direkten Aufruf ohne Anker kann der Server sofort den richtigen Inhalt liefern, mit Anker muss man noch einen Ajax-Request nach dem eigentlichen Inhalt hinterherschicken
Hmm, aber es ging ja um ein Forum ganz in AJAX?...

Der Erstaufruf des Forums geht nicht nur mit Ajax. Das muss erstmal ein "normaler" Request sein. Und der kann ja gleich alles mitliefern, was zur angefragten URL gehört, wenn jemand einen Beitrag direkt verlinkt beispielsweise. Ich seh da keinen generellen Grund, zwingend auf Ajax für den eigentlichen Inhalt zu bestehen. Außerdem sehe ich auch keinen Mehraufwand. Die Routine zum Abfragen der Daten und Aufbereiten für die Response ist vorhanden. Die wird beim herkömmlichen Aufruf ebenfalls ausgeführt und der Inhalt gleich mit in die Response gepackt.

Überhaupt, dieser zusätzliche AJAX-Request entsteht ja so oder so nur ein einziges mal (nämlich beim erstmaligen Aufruf über Lesezeichen) jeder weitere Navigatinsschritt geht ja dann direkt über AJAX...
Außer ich hab was grundsätzlich missverstanden...

Nö, aber warum zwei Requests erzeugen, wenn mit sehr wenig Aufwand ein Request reicht.

Und dann waren da auch noch die Suchmaschinen, die zumindest bisher kein Ajax gemacht haben. Die Frage ist, ob man es sich leisten kann, ein Rein-Ajax-Forum zu betreiben, dessen Inhalte nicht gefunden werden.

dedlfix.

[tinita]

Und dann waren da auch noch die Suchmaschinen, die zumindest bisher kein Ajax gemacht haben. Die Frage ist, ob man es sich leisten kann, ein Rein-Ajax-Forum zu betreiben, dessen Inhalte nicht gefunden werden.

Siehe dazu ähnliches bei disqus:

http://www.quora.com/Does-Disqus-hurt-SEO-for-Blogs-Why-why-not

[Camping_RIDER]

Aloha ;)

Grundsätzlich stimme ich dir für den ersten Aufruf zu, das stimmt schon. Trotzdem ist der Mehr-Traffic verhältnismäßig gering.

Und dann waren da auch noch die Suchmaschinen, die zumindest bisher kein Ajax gemacht haben. Die Frage ist, ob man es sich leisten kann, ein Rein-Ajax-Forum zu betreiben, dessen Inhalte nicht gefunden werden.

Wie ich an anderer Stelle schon geschrieben habe, sehe ich ein solches AJAX-Forum so oder so eher als Zusatz-Feature für themenbezogene Diskussionen und nicht als Hauptinhalt einer Seite. Sobald dieses Feature einen solchen Stellenwert hat, dass ein Suchmaschinen-Listing nötig ist, hat es in meinen Augen seinen Zweck verfehlt und sollte durch ein "normales" Forum ersetzt werden, man denke auch mal an die Leute, die aus Prinzip JavaScript deaktiviert haben. JavaScript-Einsatz für Haupt-Features ist sowieso immer zu überdenken...

Grüße,

RIDER

[M.]

Mahlzeit,

Grundsätzlich stimme ich dir für den ersten Aufruf zu, das stimmt schon. Trotzdem ist der Mehr-Traffic verhältnismäßig gering.

Lass mich raten, du warst noch nie mit einer langsamen mobilen Internetverbindung in einem Forum. Da kann ein zusätzlicher Request mal schnell ne halbe Minute ausmachen.
Der Traffic speitl keine Rolle, aber wie siehst du die Chance, dass jemand diese Zeit wartet, bevor er die Seite wieder schliesst? Ich sehe sie als extrem hoch.

[Camping_RIDER]

Aloha ;)

Lass mich raten, du warst noch nie mit einer langsamen mobilen Internetverbindung in einem Forum.

Da hast du Recht, ertappt :D Im Allgemeinen vermeide ich Internet aus der Dose, das verwende ich nur in allerhöchsten Notsituationen xD

Da kann ein zusätzlicher Request mal schnell ne halbe Minute ausmachen.
Der Traffic speitl keine Rolle, aber wie siehst du die Chance, dass jemand diese Zeit wartet, bevor er die Seite wieder schliesst? Ich sehe sie als extrem hoch.

Okay, erwischt, ich hab Mobilgeräte nicht bedacht. Für diesen Fall gebe ich mich tatsächlich geschlagen, wiederrufe und behaupte in Zukunft das Gegenteil ;)

Grüße,

RIDER

[hotti]

Wollt' ich schon immer mal machen. Wer möchte, kann sich das mal hier anschauen.

[1UnitedPower]

Meine Damen und Herren, habe ich Ihre Aufmerksamkeit?

Wollt' ich schon immer mal machen. Wer möchte, kann sich das mal hier anschauen.

Noch ein paar Vorschläge:

• Tausche die Layout-Tabelle für das Antwort-Formular gegen semantisches HTML5.
• Benutze das <form>-Element, um das Formular logisch auszuzeichnen.
• Benutze <label>-Elemente für die Feld-Bezeichner.
• Benutze <button>-Elemente für Aktionen, keine Text-Paragraphen <p>.
• Verwende die nativen Validierungs-Funktionen des Browsers, zum Beispiel das required-Attribut. Die Validierungs-Funktionen kannst du auch programmatisch ansteuern.
• Gib den Eingabefeldern eine angemessene Größe.
• Spare bei den vielen Rahmen, die lassen das Formular total nervös wirken, weniger ist manchmal mehr.
• Die Vorschau würde ich mit einem <output>-Element auszeichnen.
• Vermeide Inline-Styles.
• Sieh dir die Seite mal auf einem Smartphone an, oder simuliere eins mit deinen Browser-Entwickler-Werkzeugen, dann wirst du sehen, dass da einige Elemente völlig unleserlich sind.
• Benutze nicht die HTTP-Methode "PUT", um Inhalte nur zu lesen. Dafür ist "GET" angebracht.
• Mache erkenntlich, welche Elemente anklickbar sind.

Weiterhin viel Spaß mit deinem Projekt.

[Gunnar Bittersmann]

@@1UnitedPower:

nuqneH

Noch ein paar Vorschläge:

• Tausche die Layout-Tabelle für das Antwort-Formular gegen semantisches HTML5.
• Benutze das <form>-Element, um das Formular logisch auszuzeichnen.
• Benutze <label>-Elemente für die Feld-Bezeichner.
• Benutze <button>-Elemente für Aktionen, keine Text-Paragraphen <p>.

Das sind keine Vorschläge. Sondern Notwendigkeiten!

Qapla'

[Camping_RIDER]

Aloha ;)

Natürlich noch nicht perfekt umgesetzt (das war aber wenn ich dich richtig verstanden hab auch gar noch nicht deine Intention), aber ansonsten finde ich die Idee und das Projekt mega-genial! Zumal Ajax-betriebene Sachen manchmal auch für den User "flüssiger" laufen als klassische rein php/html basierte konzepte...

Trotzdem eher geeignet wie schon erwähnt als Diskussionsforum zu einer bestimmten Seite o.ä., nicht als Ersatz für ein richtiges Forum (es sollte denke ich mehr Zusatzfeature als Hauptinhalt sein, sonst habe ich da echte Schwierigkeiten mit Barrierefreiheit/abgeschaltetem Javascript...). Aber für diesen Zweck: Klasse, Daumen hoch, weiterentwickeln! :D

Grüße,

RIDER

[tinita]

aber ansonsten finde ich die Idee und das Projekt mega-genial!

ja, wenn man ajax-anwendungen (nur als beispiel trello.com) und per ajax eingebundene diskussionsforen (als beispiel disqus.com) noch gar nicht kennt, mag das tatsächlich genial erscheinen =)
disqus kommt übrigens ohne proxy-acl-negotiation-foo-bar aus.

[Camping_RIDER]

Aloha ;)

ja, wenn man ajax-anwendungen (nur als beispiel trello.com) und per ajax eingebundene diskussionsforen (als beispiel disqus.com) noch gar nicht kennt, mag das tatsächlich genial erscheinen =)

:D ein Konzept kann auch genial sein, wenn es etliche vorher auch schon benutzt haben xD ich sagte ja nur genial, nicht einzigartig ;) Die vielfache Benutzung unterstreicht ja eben die Genialität :D

Schrieb der registrierte Trello-Nutzer :P

Grüße,

RIDER