Question

我们实际上使用Symfony 2 PHP框架和Twig作为模板引擎。我们认为我们可以避免View层的代码重复，并从渐进增强（p-jax）中受益。

现状：

PJAX不会根据路径处理页面布局的部分更新。我们的目标是实现一个系统，当Y.App（路由）处理导航时，只会更新一些页面“片段”（HTML节点）。

在这方面，我们开始在https://github.com/benjamindulau/PocSfYui/实施POC 可在此处找到Javascript：https://github.com/benjamindulau/PocSfYui/tree/master/src/Acme/PocBundle/Resources/public/js 和Y.App初始配置：https://github.com/benjamindulau/PocSfYui/blob/master/src/Acme/PocBundle/Resources/views/layout.html.twig#L66

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

这基本上是当前视图内容（路线）的“JSONified”版本。

在服务器端，我们检测到请求来自Y.App而不是呈现我们的Twig模板，我们从中提取“块”并构造此JSON响应，其中包含需要更新的页面片段+车把模板客户需要此特定页面。

在客户端（Y.App）：

我们定义了一个表示整个页面布局的基本PageCompositeView，然后是一个继承自此的Page2colLeftView并实现了自己的子视图：SidebarView，MainView，HeaderView，....
我们写了一个IO模块来伪造我们的PJAX-Like请求。我们使用它而不是“loadContent”（参见：https://github.com/benjamindulau/PocSfYui/blob/master/src/Acme/PocBundle/Resources/views/layout.html.twig#L93）
在首次加载时，我们调用showView并尝试将页面子视图“重新连接”到各自的容器中（请参阅：https://github.com/benjamindulau/PocSfYui/blob/master/src/Acme/PocBundle/Resources/public/js/views/page.js#L27）
在页面中导航时，Y.App知道页面结构。

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

2和3（特别是3）是手动完成的。

POC实际上有效。

但在走得更远之前，我们很乐意得到你的建议。

首先，您对此POC有何看法？

我们实际上看到了专业人士这种方法有利。

我们主要关注的是如何调整Y.App来实现我们想要的目标： - 单个复合视图 - 首次加载时，通过读取现有DOM重新补充模型（即：当服务器呈现照片列表时） - 我们向前发展的越多，我们就越认为我们错过了关于Y.App的一些东西，我们认为它错了; - ）

但关于这一切的积极方面是我们可以在没有那么多工作的情况下构建一个完整的异步网站。

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

可能从该消息中出现的主要问题是：

“我们正在以正确的方式使用Y.App吗？” ; - ）

那么，您怎么看？

谢谢， CYA

Answer 1

对于CMS管理的POC，我做了几乎相同但有两点不同：PJAX响应仍然是一个HTML片段，它包含一个带有JSON编码数据的脚本标记，所以不是查询DOM来重新水合我的模型/模型列表，我们使用其中已有的数据。这允许不依赖任何标记来获得正确的模型，但另一方面，这使得响应的大小更大（但仍然比整页加载轻得多）。

此外，JSON编码数据可能还包含一些设置，例如告诉Y.App使用哪些视图，在哪里查找相应的DOM，模板或其他...

这在YUILibrary论坛上讨论过：http://yuilibrary.com/forum/viewtopic.php?t=11877所以你可以在这里找到其他详细信息。

对于“我们是否以正确的方式使用Y.App？”问题，我认为没有真正的回应。我的意思是YUI App框架是一种允许你做任何你想做的框架，只是考虑到你的约束，这只是权衡问题。如果你看几个YUI应用程序的例子，它们都有一个非常不同的策略。

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

使用YUI3（Y.App）和Symfony2逐步增强

1 个答案: