Progressive enhancement with YUI3 (Y.App) and Symfony2
Asked Answered
F

1

9

We actually work with the Symfony 2 PHP framework and Twig as a template engine. We think that we could avoid code duplication for the View layer and benefit from progressive enhancement (p-jax).

Current status:

PJAX doesn't handle partial updates of the page layout based on route. Our goal is to implement a system where only some page "fragments" (HTML nodes) would be updated when navigation is handled by Y.App (routing).

In this regard we started to implement a POC at: https://github.com/benjamindulau/PocSfYui/ Javascript can be found here: https://github.com/benjamindulau/PocSfYui/tree/master/src/Acme/PocBundle/Resources/public/js And Y.App initial configuration there: https://github.com/benjamindulau/PocSfYui/blob/master/src/Acme/PocBundle/Resources/views/layout.html.twig#L66

The idea is that when we first load the page, everything is handled server-side (progressive enhancement), meaning that the whole page and page fragments are rendered by the server. For the next requests, which should be performed by Y.App, we defined a JSON format like the following (/photos path response):

{
    "title": "MyAwesomeWebsite - Photos", // page <title>,
    "fragments": {
        "sidebar": "<h2>Sidebar Menu<\/h2><!-- etc.... -->", // ..... maybe an updated menu for active page
        "main": "<h2>Photos<\/h2><div id=\"photo-list-container\"><ul id=\"photo-list\"><!-- photo items.... --></ul></div>", // Pre-rendered photo list
    },
    "templates": {
        "photo_item_tpl": "<li data-id=\"{{index}}\"><img src=\"{{url}}\" alt=\"{{title}}\" \/><\/li>" // template used later by Y.App for adding new photos
    }
}

Which is basically a "JSONified" version of the current view content (route).

On server side, we detect that the request came from Y.App and instead of rendering our Twig template, we extract "blocks" from it and construct this JSON response containing page fragments that need to be updated + handlebar templates that the client needs for this specific page.

On client side (Y.App):

Say we load directly the "/photos" path in our browser: 1. The server renders the whole page containing a photo list 2. The YUI App creates its PageCompositeView and reconnects each sub-view to its container 3. The YUI App knows that the "MainView" view (which corresponds to the main content) should contain a "PhotoListView" sub-view binded to a "PhotoModelList" model list. So a callback on "/photos" path creates the "PhotoView" instance and reconnects it to its container (rendered by the server).

2 and 3 (especially 3) are done manually.

The POC actually works.

But before going further we'd love to get your advices.

First thing first, what do you think about this POC ?

We actually see pros & cons with this approach.

Our main concern is about how we tweak Y.App to achieve what we want: - A single composite view - On first load, the models are re-hydrated by reading the existing DOM (i.e: when photo list is rendered by the server) - The more we move forward, the more we think that we're missing something about Y.App and that we took it the wrong way ;-)

But the positive side about all this is that we could build a full asynchronous website without so much work.

Our main goal is to keep everything maintenable by providing an "almost-complete" generic solution.

Maybe the main question that emerges from that message would be:

"Are we using Y.App the right way ?" ;-)

So, what do you think ?

Thanks, Cya

Flake answered 19/3, 2013 at 15:59 Comment(0)
E
0

For a POC of a CMS administration, I did pretty much the same but with 2 differences: the PJAX response is still an HTML fragment and it contains a script tag with the JSON encoded data so instead of querying the DOM to rehydrate my models/model lists, we use the data already in it. This allows to not rely on any markup to get proper models but on the other hand, this makes the size of the response a bit bigger (but still much lighter than a full page load).

In addition, the JSON encoded data might also contain some settings for instance to tell your Y.App which View(s) to use, where to find the corresponding DOM, the templates, or whatever...

This was discussed on the YUILibrary forum: http://yuilibrary.com/forum/viewtopic.php?t=11877 so you may find others details here.

For the "Are we using Y.App the right way ?" question, I think there's no real response. I mean the YUI App framework is the kind of framework that let you do whatever you want, it's only a matter of tradeoff given your constraints. If you look at the few YUI App examples, they all have a very different strategies.

But in any case, your solution seems very OK to me and I'm glad to see there are still people building progressively enhanced applications :-)

Efrenefron answered 21/3, 2013 at 9:48 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.