Progressive Erweiterung mit YUI3 (Y.App) und Symfony2

8

Wir arbeiten mit dem Symfony 2 PHP Framework und Twig als Template Engine. Wir denken, dass wir die Code-Duplizierung für die View-Ebene vermeiden und von der progressiven Erweiterung (p-jax) profitieren können.

Aktueller Status:

PJAX verarbeitet keine Teilupdates des Seitenlayouts basierend auf der Route. Unser Ziel ist es, ein System zu implementieren, bei dem nur einige Seiten- "Fragmente" (HTML-Knoten) aktualisiert werden, wenn die Navigation von Y.App (routing) ausgeführt wird.

In diesem Zusammenhang haben wir mit der Umsetzung eines POC begonnen: Ссылка Javascript kann hier gefunden werden: Ссылка Und Y.App erste Konfiguration dort: Ссылка

Die Idee ist, dass beim ersten Laden der Seite alles serverseitig gehandhabt wird (progressive Erweiterung), was bedeutet, dass die gesamte Seite und die Seitenfragmente vom Server gerendert werden. Für die nächsten Anfragen, die von Y.App durchgeführt werden sollten, haben wir ein JSON-Format wie folgt definiert (/ photos path response):

%Vor%

Dies ist im Grunde eine "JSONified" Version der aktuellen Ansicht Inhalt (Route).

Auf Server-Seite stellen wir fest, dass die Anfrage von Y.App kam und anstatt unsere Twig-Vorlage zu rendern, extrahieren wir "Blöcke" daraus und konstruieren diese JSON-Antwort, die Seitenfragmente enthält, die aktualisiert werden müssen, + Lenker-Vorlagen Client benötigt für diese bestimmte Seite.

Auf der Client-Seite (Y.App):

  • Wir haben eine base PageCompositeView definiert, die das gesamte Seitenlayout repräsentiert, und dann eine Page2colLeftView, die von dieser erbt und ihre eigenen Unteransichten einführt: SidebarView, MainView, HeaderView, ....
  • Wir haben ein IO-Modul geschrieben, das unsere PJAX-Like-Anfragen erstellt. Wir verwenden es anstelle von "loadContent" (siehe: Ссылка )
  • Beim ersten Laden rufen wir showView auf und versuchen, unsere Seitenunteransichten wieder mit ihren jeweiligen Containern zu verbinden (siehe: Ссылка )
  • Beim Navigieren in Seiten kennt Y.App die Seitenstruktur.

Sagen wir, wir laden direkt den "/ fotos" Pfad in unserem Browser:  1. Der Server rendert die gesamte Seite mit einer Fotoliste  2. Die YUI-App erstellt ihre PageCompositeView und verbindet jede Unteransicht erneut mit ihrem Container  3. Die YUI-App weiß, dass die "MainView" -Ansicht (die dem Hauptinhalt entspricht) eine "PhotoListView" -Unteransicht enthalten sollte, die an eine "PhotoModelList" -Modellliste gebunden ist. Ein Rückruf für den Pfad "/ photos" erstellt die Instanz "PhotoView" und verbindet sie erneut mit ihrem Container (der vom Server gerendert wird).

2 und 3 (besonders 3) werden manuell durchgeführt.

Der POC funktioniert tatsächlich.

Aber bevor wir weitermachen, würden wir uns sehr über Ihre Ratschläge freuen.

Zunächst einmal, was denkst du über diesen POC?

Wir sehen tatsächlich Pros & amp; Nachteile mit diesem Ansatz.

Unser Hauptanliegen ist, wie wir Y.App optimieren, um das zu erreichen, was wir wollen:  - Eine einzelne zusammengesetzte Ansicht  - Beim ersten Laden werden die Modelle durch Lesen des vorhandenen DOM erneut hydratisiert (d. H. Wenn die Fotoliste vom Server gerendert wird)  - Je mehr wir uns vorwärts bewegen, desto mehr denken wir, dass wir etwas an Y.App vermissen und dass wir es falsch verstanden haben; -)

Aber das Positive an all dem ist, dass wir ohne viel Arbeit eine vollständige asynchrone Website erstellen können.

Unser Hauptziel ist es, alles mit einer "fast vollständigen" generischen Lösung aufrechtzuerhalten.

Vielleicht lautet die Hauptfrage, die sich aus dieser Botschaft ergibt:

"Verwenden wir Y.App auf die richtige Weise?" ; -)

Also, was denkst du?

Danke, Cya

    
Benjamin 19.03.2013, 15:59
quelle

1 Antwort

0

Für einen POC einer CMS-Administration habe ich fast dasselbe gemacht, aber mit zwei Unterschieden: Die PJAX-Antwort ist immer noch ein HTML-Fragment und enthält ein Skript-Tag mit den JSON-codierten Daten, also statt das DOM zu rehydrieren Modelle / Modelllisten verwenden wir die bereits darin enthaltenen Daten. Dies erlaubt es, sich nicht auf irgendwelche Markups zu verlassen, um korrekte Modelle zu erhalten, aber auf der anderen Seite macht dies die Größe der Antwort ein bisschen größer (aber immer noch viel leichter als eine volle Seitenladung).

Außerdem können die JSON-kodierten Daten auch einige Einstellungen enthalten, um zB Ihrer Y.App mitzuteilen, welche Views verwendet werden sollen, wo das entsprechende DOM, die Templates oder was auch immer zu finden ist ...

Dies wurde auf dem YUILibrary-Forum diskutiert: Ссылка , damit Sie hier weitere Details finden können.

Für die "Verwenden wir Y.App den richtigen Weg?" Frage, ich denke, es gibt keine echte Antwort. Ich meine, das YUI App-Framework ist die Art von Framework, mit dem Sie tun können, was immer Sie wollen, es ist nur eine Frage des Kompromisses angesichts Ihrer Einschränkungen. Wenn Sie sich die wenigen YUI App-Beispiele ansehen, haben sie alle sehr unterschiedliche Strategien.

Aber auf jeden Fall scheint mir Ihre Lösung sehr OK zu sein und ich bin froh zu sehen, dass immer noch Leute progressiv erweiterte Anwendungen erstellen: -)

    
Damien 21.03.2013 09:48
quelle