YUI3 (y.p app)和Symfony2的渐进增强

我们实际上使用Symfony 2 PHP框架和Twig作为模板引擎。我们认为我们可以避免视图层的代码重复，并受益于渐进式增强(p-jax)。

目前状况:PJAX不处理基于路由的页面布局的部分更新。我们的目标是实现一个系统，当y.p p(路由)处理导航时，只有一些页面"片段"(HTML节点)会被更新。

在这方面，我们开始在:https://github.com/benjamindulau/PocSfYui/实现POCJavascript可以在这里找到:https://github.com/benjamindulau/PocSfYui/tree/master/src/Acme/PocBundle/Resources/public/jsy.p p的初始配置:https://github.com/benjamindulau/PocSfYui/blob/master/src/Acme/PocBundle/Resources/views/layout.html.twig#L66

这个想法是，当我们第一次加载页面时，一切都在服务器端处理(渐进式增强)，这意味着整个页面和页面片段都由服务器呈现。对于应该由y.p p执行的下一个请求，我们定义了如下的JSON格式(/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
    }
}

这基本上是当前视图内容(路由)的"jsonized"版本。

在服务器端，我们检测到请求来自y.p app，而不是呈现我们的Twig模板，我们从中提取"块"，并构建这个JSON响应，其中包含需要更新的页面片段和客户端需要的这个特定页面的车把柄模板。

客户端(y.p app):

我们定义了一个基本的PageCompositeView，它代表了整个页面的布局，然后一个Page2colLeftView继承了这个，并实例化了自己的子视图:SidebarView, MainView, HeaderView， ....
在第一次加载时，我们调用showView并尝试"重新连接"我们的页面子视图到各自的容器(参见:https://github.com/benjamindulau/PocSfYui/blob/master/src/Acme/PocBundle/Resources/public/js/views/page.js#L27)
在页面中导航时，y.p p知道页面的结构。

假设我们直接在浏览器中加载"/photos"路径:1. 服务器呈现包含照片列表的整个页面2. YUI应用程序创建它的PageCompositeView，并将每个子视图重新连接到它的容器3.YUI App知道"MainView"视图(对应于主内容)应该包含一个绑定到"PhotoModelList"模型列表的"PhotoListView"子视图。因此，在"/photos"路径上的回调创建了"PhotoView"实例，并将其重新连接到它的容器(由服务器渲染)。

2和3(特别是3)是手动完成的。

POC实际工作。

但在进一步讨论之前，我们想听听你的建议。

首先，你觉得这个POC怎么样?

我们实际上看到了pros &这种方法的缺点。

我们主要关心的是如何调整y.p p来实现我们想要的:-单个复合视图在第一次加载时，通过读取现有的DOM(即:当照片列表被服务器渲染时)来重新填充模型。-我们越往前走，我们越觉得我们错过了y.p p的一些东西，我们采取了错误的方式;-)

但这一切积极的一面是，我们可以建立一个完整的异步网站，而不需要这么多的工作。

我们的主要目标是通过提供一个"几乎完整"的通用解决方案来保持一切都是可维护的。

也许从这个消息中出现的主要问题是:

"我们使用y.p p的方式正确吗?";-)

你觉得呢?

谢谢,自保"

对于CMS管理的POC，我做了几乎相同的事情，但有2个不同之处:PJAX响应仍然是一个HTML片段，它包含一个带有JSON编码数据的脚本标记，所以我们使用已经在其中的数据而不是查询DOM来补充我的模型/模型列表。这允许不依赖任何标记来获得适当的模型，但另一方面，这使得响应的大小有点大(但仍然比整个页面加载轻得多)。

此外，JSON编码的数据也可能包含一些设置，例如告诉你的y.p要使用哪个视图，在哪里找到相应的DOM，模板，或任何…

这是在yulibrary论坛上讨论的:http://yuilibrary.com/forum/viewtopic.php?t=11877所以你可以在这里找到其他细节。

对于"我们使用y.p p的方式正确吗?"这个问题，我认为没有真正的回应。我的意思是YUI App框架是那种允许你做任何你想做的事情的框架，它只是一个给定约束条件的权衡问题。如果你看几个YUI App的例子，它们都有非常不同的策略。

但无论如何，你的解决方案对我来说似乎很好，我很高兴看到仍然有人在构建逐步增强的应用程序:-)

相关内容

最新更新

热门标签：