Entwurf eines grundlegenden Prototyps
Werbung
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 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 Seite anhand des URL-Pfads bestimmen Seitenmodul auslesen Modulbaum rekursiv rendern (Tiefensuche): 1. 2. 3. a. b. c. 4. Direkte Kindmodule ermitteln und jeweils neue Rekursion anstoßen Gerenderte Untermodule in eigenes Rendering-Ergebnis einbeziehen Ergebnis im Cache speichern und an übergeordneten Prozess hochreichen 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 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) 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 Wird gesuchtes Modul gerendert, zusätzlichen Parameter leeren Seite wird „normal“ gerendert, gesuchtes Modul als zusätzlicher Parameter 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 Fertige HTML-Bausteine Geringes Datenvolumen Nahtlose Einbettung in bestehende Daten möglich 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 Anfrage im Javascript abschicken z.B. mit jQuery.ajax() oder den spezialisierten post() und get() Antwort im Javascript verarbeiten z.B. mit Smarty-Plugin admon_generate_link Zusätzlich benötigte Modul-Parameter sind im Modul selbst bekannt 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, http://adaptivepath.org/ideas/ajax-new-approach-web-applications/, 2005 (besucht 13.12.2015) [jqua] (jQuery-Dokumentation) jQuery.ajax(), http://api.jquery.com/jquery.ajax/, (besucht 13.12.2015) [jqub] (jQuery-Dokumentation) jQuery.get(), http://api.jquery.com/jquery.get/, (besucht 13.12.2015) [jquc] (jQuery-Dokumentation) jQuery.post(), http://api.jquery.com/jquery.post/, (besucht 13.12.2015) Fragen? Vielen Dank für die Aufmerksamkeit!
