Seminararbeit im Studiengang „Scientific Programming“ Kontextgebundene Bausteine einer Webseite mit AJAX dynamisch aktualisieren Lukas Rüttgers Matr.-Nr.: Prüfer: Prof. Dr. rer. nat. Volker Sander, FH Aachen Betreuer: Martin Jansen, Bauer+Kirch GmbH

Agenda 1. Motivation 2. Analyse bestehender Implementierungen 3. Entwurf eines grundlegenden Prototyps 4. Abhängigkeiten 5. Caching 6. Ausgabeformate 7. Verwendung 8. Ausblick

Agenda 1. Motivation 2. Analyse bestehender Implementierungen 3. Entwurf eines grundlegenden Prototyps 4. Abhängigkeiten 5. Caching 6. Ausgabeformate 7. Verwendung 8. Ausblick

Motivation  Datenvolumen und Ladezeit von Webseiten reduzieren  In vielen Gegenden nur geringe Datenrate verfügbar  Immer mehr Zugriffe über Mobilfunknetze (→ Kosten)  Aber: Größe und Komplexität vieler Webseiten steigt  Ansatz: AJAX (Asynchronous Javascript and XML)  Teilinhalte nachträglich laden  Hauptinhalt schneller verfügbar

Anwendung: „Admon:CMS“  Unterseiten der Webpräsenz  Baumstruktur  URL-Pfad entspricht Pfad durch Baum  Inhalte (Module)  pro Seite: Baumstruktur  global: gerichteter, nicht zirkulärer Graph (verknüpfte Module)  Wurzel des lokalen Modul-Baums („Seitenmodul“) in Seite verknüpft

Probleme / Anforderungen:  URL zeigt immer auf gesamte Seite  Einzelnes Modul ansprechen / auswählen  Ergebnis ohne restliche Seite ausgeben  Abhängigkeiten auf modul-externe Werte  Ergebnisse müssen im Cache gespeichert werden können  Sicherheitsstandards müssen beachtet werden  Abwärtskompatibilität von Admon:CMS soll erhalten bleiben  Auswirkungen der Änderungen möglichst gering halten

Agenda 1. Motivation 2. Analyse bestehender Implementierungen 3. Entwurf eines grundlegenden Prototyps 4. Abhängigkeiten 5. Caching 6. Ausgabeformate 7. Verwendung 8. Ausblick

Analyse bestehender Implementierungen  Reload auf anderen Status des Moduls  Modul kann geänderte Parameter verarbeiten  Abhängigkeiten vollständig auflösbar  Ergebnis kann im Cache gespeichert werden  Komplette Seite muss neu geladen werden  Individuelles API-Modul  Einzelner Inhalt via AJAX abrufbar  Ergebnis kann im Cache gespeichert werden  Abhängigkeiten evtl. nicht auflösbar  Doppelter Code

Agenda 1. Motivation 2. Analyse bestehender Implementierungen 3. Entwurf eines grundlegenden Prototyps 4. Abhängigkeiten 5. Caching 6. Ausgabeformate 7. Verwendung 8. Ausblick

Entwurf eines grundlegenden Prototyps  Module erhalten eine implizite API  Kombination der Vorteile der bestehenden Lösungsansätze  Wie kann diese API angesprochen werden?  Wie kann das Ergebnis eines Moduls einzeln ausgegeben werden?

Analyse des Rendering-Vorgangs 1. Seite anhand des URL-Pfads bestimmen 2. Seitenmodul auslesen 3. Modulbaum rekursiv rendern (Tiefensuche): a. Direkte Kindmodule ermitteln und jeweils neue Rekursion anstoßen b. Gerenderte Untermodule in eigenes Rendering-Ergebnis einbeziehen c. Ergebnis im Cache speichern und an übergeordneten Prozess hochreichen 4. Fertige Seite ausgeben

Analyse des Rendering-Vorgangs

Entwurf eines grundlegenden Prototyps  Angabe des zu rendernden Moduls als GET-Parameter  Modul-ID im Javascript bekannt  Gewähltes Modul statt Seitenmodul in rekursiven Prozess geben  Gewähltes Modul wird samt aller Untermodule normal gerendert  Eltern- und Geschwistermodule werden ignoriert  Nur Ergebnis des Moduls (und etwaiger Untermodule) wird ausgegeben Gewöhnlicher Aufruf einer Seite, auf der im Beispiel ein Listenmodul seine zweite Seite darstellen soll Direkte Anfrage an die implizite API des Listenmoduls (hier mit ID 5), die zweite Seite der Liste darzustellen (ohne die anderen Module außenherum zu rendern)

Agenda 1. Motivation 2. Analyse bestehender Implementierungen 3. Entwurf eines grundlegenden Prototyps 4. Abhängigkeiten 5. Caching 6. Ausgabeformate 7. Verwendung 8. Ausblick

Abhängigkeiten  Prehandler  Callback, der zu Beginn des Renderings eines Moduls ausgeführt wird  Kann Informationen, die dem Modul exklusiv bekannt sind, an Kinder weitergeben  Posthandler  Callback, der auf dem Rendering-Ergebnis ausgeführt wird  Nachdem das Ergebnis im Cache gespeichert wurde (→ Änderung nicht im Cache)  Kann für Edge Side Includes verwendet werden

Anpassung des Prototyps  Seitenmodul und gesuchtes Modul in rekursiven Prozess geben  Seite wird „normal“ gerendert, gesuchtes Modul als zusätzlicher Parameter  Wird gesuchtes Modul gerendert, zusätzlichen Parameter leeren  Gesuchtes Modul und Kinder werden ohne zus. Parameter gerendert  Ist gesuchtes Modul gesetzt, das eigentliche Rendering überspringen  Stattdessen nichts oder Ergebnis eines Kindes zurückgeben, sofern vorhanden → nur gesuchtes Modul und Kinder werden gerendert, für alle anderen Module der Seite werden aber u.a. Pre- und Posthandler ausgeführt.

Agenda 1. Motivation 2. Analyse bestehender Implementierungen 3. Entwurf eines grundlegenden Prototyps 4. Abhängigkeiten 5. Caching 6. Ausgabeformate 7. Verwendung 8. Ausblick

Caching  URL-Pfad als Cache-Key für gesamte Seite  Neuen GET-Parameter ebenfalls in den Key übernehmen  Einzelne Module unter ID gespeichert  Bei leer gerenderten Modulen Cache-Key mit ID des gesuchten Moduls erweitern

Agenda 1. Motivation 2. Analyse bestehender Implementierungen 3. Entwurf eines grundlegenden Prototyps 4. Abhängigkeiten 5. Caching 6. Ausgabeformate 7. Verwendung 8. Ausblick

Ausgabeformate  Rohdaten als JSON  Geringes Datenvolumen  Nahtlose Einbettung in bestehende Daten möglich  Fertige HTML-Bausteine  Komplexere Rendering-Prozesse serverseitig erledigen  Direkte Ersetzung des alten Bausteins möglich  Beliebige weitere Formate  Individuelle Bedürfnisse

Umsetzung  Modul-Parameter (GET)  Im Modulcode entsprechende Ausgabe steuerbar  Bei normalem Seitenaufruf viele leere Parameter → unschöne URL  Channel  Automatisch passendes Template genutzt  Bestehender HTTP-GET-Parameter

Agenda 1. Motivation 2. Analyse bestehender Implementierungen 3. Entwurf eines grundlegenden Prototyps 4. Abhängigkeiten 5. Caching 6. Ausgabeformate 7. Verwendung 8. Ausblick

Verwendung  Erzeuge URL zu aktueller Seite mit Modul-ID und Channel  z.B. mit Smarty-Plugin admon_generate_link  Zusätzlich benötigte Modul-Parameter sind im Modul selbst bekannt  Anfrage im Javascript abschicken  z.B. mit jQuery.ajax() oder den spezialisierten post() und get()  Antwort im Javascript verarbeiten  z.B. mit jQuery alten HTML-Baustein selektieren und durch neuen ersetzen  Webcrawler und Nutzer ohne JS berücksichtigen  Parallele Implementierung mit vollständigem Neuladen individuell je Modul  Javascript-Variante deaktiviert Parallel-Implementierung

Agenda 1. Motivation 2. Analyse bestehender Implementierungen 3. Entwurf eines grundlegenden Prototyps 4. Abhängigkeiten 5. Caching 6. Ausgabeformate 7. Verwendung 8. Ausblick

Ausblick  Feature in erarbeiteter Form bereits verwendbar  Problem: HTTP-Requests für Nutzer sichtbar  Manipulation möglich  Für sensible Daten nur bedingt nutzbar → Vereinigung von Geschwindigkeit und Sicherheit für Bachelorarbeit geplant

Verwendete Literatur  [Jes05] Jesse James Garrett, A New Approach to Web Applications, (besucht )  [jqua] (jQuery-Dokumentation) jQuery.ajax(), (besucht )  [jqub] (jQuery-Dokumentation) jQuery.get(), (besucht )  [jquc] (jQuery-Dokumentation) jQuery.post(), (besucht )

Fragen?

Vielen Dank für die Aufmerksamkeit!