Seminararbeit im Studiengang „Scientific Programming“ Kontextgebundene Bausteine einer Webseite mit AJAX dynamisch aktualisieren Lukas Rüttgers Matr.-Nr.:

Präsentation zum Thema: "Seminararbeit im Studiengang „Scientific Programming“ Kontextgebundene Bausteine einer Webseite mit AJAX dynamisch aktualisieren Lukas Rüttgers Matr.-Nr.:"—  Präsentation transkript:

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

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

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

4 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

5 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

6 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

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

8 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

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

10 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?

11 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

12 Analyse des Rendering-Vorgangs

13 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 http://www.example.com/beispielseite/2/ Gewöhnlicher Aufruf einer Seite, auf der im Beispiel ein Listenmodul seine zweite Seite darstellen soll http://www.example.com/beispielseite/2/?module=5 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)

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

15 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

16 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.

17

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

19 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

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

21 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

22 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

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

24 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

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

26 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

27 Verwendete Literatur  [Jes05] Jesse James Garrett, A New Approach to Web Applications, http://adaptivepath.org/ideas/ajax-new-approach-web-applications/, 2005 (besucht 13.12.2015) http://adaptivepath.org/ideas/ajax-new-approach-web-applications/  [jqua] (jQuery-Dokumentation) jQuery.ajax(), http://api.jquery.com/jquery.ajax/, (besucht 13.12.2015) http://api.jquery.com/jquery.ajax/  [jqub] (jQuery-Dokumentation) jQuery.get(), http://api.jquery.com/jquery.get/, (besucht 13.12.2015) http://api.jquery.com/jquery.get/  [jquc] (jQuery-Dokumentation) jQuery.post(), http://api.jquery.com/jquery.post/, (besucht 13.12.2015) http://api.jquery.com/jquery.post/

28 Fragen?

29 Vielen Dank für die Aufmerksamkeit!