Widget-Inhalt aktualisieren

[MrT]

Hallo ihr :-)

...ich habe eine grundsätzliche Frage zu Widgets.

Nehmen wir einmal an, ein Widget stellt Inhalte aus einer DB dar und soll, wie auch immer, aktuell gehalten werden. Das heisst, wenn immer sich der DB-Inhalt ändert, soll das Widget aktualisiert werden. Wie würdet ihr das lösen?

Ich stelle mir einen DB-Trigger vor, der, wenn DB-Inhalte geändert werden, aktiv wird und ein PHP-Skript anstösst. Dieses generiert dann einen (Atom-/RSS-) Feed, der vom Widget überwacht wird und die Aktualisierung des Widgets auslöst.

Ist das zu kompliziert, bzw. geht es einfacher?

...ich freu mich über alle Anregungen (aber bitte keine Diskussionen, welches Feed-Format besser ist ;-)!

Gruss,

-T

[Tim Tepaße]

Hallo,

...ich habe eine grundsätzliche Frage zu Widgets.

Widgets können sein ... Die Dinger aus Apples Dashboard oder neuerdings auch Javascript-Klumpen, die man in eine Webseite einbetten kann. Das Prinzip ist dasselbe.

Ich stelle mir einen DB-Trigger vor, der, wenn DB-Inhalte geändert werden, aktiv wird und ein PHP-Skript anstösst. Dieses generiert dann einen (Atom-/RSS-) Feed, der vom Widget überwacht wird und die Aktualisierung des Widgets auslöst.

Für so etwas gibt es sogar einen Fachbegriff, AppCasting, auch wenn es sich eher auf das Selbstupdate von Software bezieht.

Ist das zu kompliziert, bzw. geht es einfacher?

Ich würde sogar sagen ja. Das hängt aber davon ab, was Du dem Widget kommunizieren willst:

Entweder: „Hier, es gibt diverse Updates zu den und den Zeitpunkten mit diesen und jenen Metadaten.“

Dann würde ich einen Feed nehmen, jedes Update mit umfangreichen Metadaten würde dann in diesem durch einen Eintrag repräsentiert.

Oder aber: „Es gibt was Neues, hol es Dir.“

Sprich: Was neu ist, ist nicht relevant, nur dass sich etwas verändert hat. In diesem Fall würde ich gar nicht den Umweg über Feeds gehen, sondern einfach HTTP und dessen umfangreiche Möglichkeiten des Conditional Requests und des Cachings nutzen.

Deine durch das Widget darzustellenden Datenbankinhalte kriegst Du sicherlich mittels eines GETs auf eine URL, also z.B. http://example.org/db.php. Beim ersten Mal wird über HTTP ein ganz normaler Request abgesetzt:

~~~http GET /db.php HTTP/1.1
  Host: example.org

  
... und der Server beantwortet diesen:  
  
  ~~~http
HTTP/1.1 200 OK  
  Date: Tue, 31 Jul 2007 22:00:00 GMT  
  Last-Modified: Tue, 31 Jul 2007 21:00:00 GMT  
  Content-Type: application/json; charset=UTF-8  
  
  { "Daten": "Hier z.B. mal im JSON-Format",  
    "Wenn":  "Ich nichts falsch tippe" }

Beim nächsten Mal, wenn der Client nachfragt schickt er die Informationen (Last-Modified und/oder Etag) einfach mit. Er fragt also „Gibt's etwas Neues seit diesem Zeitpunkt?“

~~~http GET /db.php HTTP/1.1
  Host: example.org
  If-Modified-Since: Tue, 31 Jul 2007 21:00:00 GMT

  
Hat sich was geändert seit diesem Zeitpunkt, schickt der Server dann die ganze neue Version. Hat sich dagegen nichts geändert, teilt er einfach mit, dass sich nichts geändert hat:  
  
  ~~~http
HTTP/1.1 304 Not Modified  
  Date: Tue, 31 Jul 2007 22:00:00 GMT

(Vereinfacht dargestellt, natürlich. HTTP kann auch Versionbezeichnungen (Etags) um zwei Versionen einfach mittels einer Bezeichnung (z.B. einem Hash) vergleichen zu können und nicht so explizites Caching mittels Auslaufzeiten und solchen Spässken.)

Der Trick ist: Wenn man solche Möglichkeiten von HTTP nutzt, dann muss man clientseitig nicht den großen Aufwand des Vergleichens und Speichers der Metadaten früherer Versionen machen. Im Idealfall übernimmt der HTTP-Client das ganze und meldet sich eben nur, wenn es eine Änderung gibt. Und schon hat man einfach nur einen regelmäßig pollenden XMLHttpRequest. Und dessen Caching wird bequemerweise vom Browser übernommen.

Das setzt natürlich vorraus, dass db.php in diesem Konzept auch die richtigen Entity Tags oder Last-Modified-Header setzt; man muss sich also dort etwas damit auseinandersetzen, was man über die Leitung schickt. Aber das war auch bei Deinem Vorschlag ja der Fall. Wie man das löst, hängt dann von den konkreten Gegebenheiten ab. Der DB-Trigger, der ein kleines Flag setzt, das ein PHP-Skript leicht auslesen kann ohne eine große, kostende Datenbankoperation klingt auf mich schon gut. Aber dies war nur ein Vorschlag zum Transport der „Es gibt was Neues“-Information.

Nebenbei: All dieses HTTP-Caching wäre natürlich auch relevant, wenn Du die Feed-Lösung wählst. Der HTTP-Client des Widgets müsste dann nicht immer den ganzen Feed runterladen sondern nur den geänderten – geeignete Logik im PHP-Skript vorausgesetzt.

...ich freu mich über alle Anregungen (aber bitte keine Diskussionen, welches Feed-Format besser ist ;-)!

Erübrigt sich eh, Atom. ;)

Tim

[MrT]

Hallo Tim,

danke dir, für deinen ausführlichen und sachdienlichen Post. :-)

Gruss,

-T

P.S.: Ich hatte, wenn Feeds verwendet werden sollten, auch an Atom gedacht...