6

我想知道在 Web 应用程序中呈现部分视图的好方法（或推荐方法）是什么。

我有一个要求，我需要使用 AJAX 将数据加载到已经呈现的页面中，有点像页面末尾的“加载更多...”链接，它从服务器获取更多信息并将其呈现到底部这页纸。

我目前正在使用的 AJAX 响应的两个选项是

  1. 返回数据的 JSON 表示，并使用客户端模板库（例如 jQuery 模板）或纯 JavaScript 将 JSON 转换为 HTML 并附加到页面底部
  2. 在服务器上渲染部分视图（在我的情况下使用 grails' render template:'tmplt_name'）并通过网络发送它并将结果附加到页面底部

还有其他方法可以做到这一点吗？如果不是，考虑到上述选项，在维护、性能和可测试性方面哪个更好？我可以肯定的一件事是，JSON 路由（在大多数情况下）将比通过网络发送 html 占用更少的带宽。

4

3 回答 3

2

这实际上是一个非常有趣的问题，因为它暴露了一些有趣的设计决策。

我更喜欢渲染部分模板，因为它使我的应用程序能够随时间变化。如果我需要使用图表从 a 更改为 a <table>，<div>可以很容易地将其封装在模板中。考虑到这一点，我将几乎每个页面都视为许多小模板的集合，这些模板可能会发生变化。Grails 2.0 默认的脚手架已经转向这种方法，这是一个好主意。

关于它们应该是客户端模板还是服务器端的问题是问题的症结所在。

服务器端模板使您的标记在初始页面加载时保持清洁。即使您使用ICanHazJS的Mustache之类的东西，您也需要在页面中有一个空元素（与您的模板一起使用），适当地对其进行样式设置，并在 Javascript 中使用它以更新您的信息。

缺点

  • “健谈”的应用程序
  • 网络上更大的信封（响应包括 HTML，可能被认为是静态的）
  • 较慢的 UI 响应时间

好处

  • 适合具有大量服务器端语言经验的人
  • 在服务器端环境中可能更容易操作或修改（例如返回嵌入了多个模板的页面，这些模板以编程方式加载和包含）
  • 将大部分应用程序的东西“放在一个地方”

然而，客户端模板确实可以减少服务器负载。他们使应用程序“不那么闲聊”，因为您可以通过发回更大的 JSON 集合（以相同数量或更少的字节数，将由 HTML 在服务器端模板方案）。它们还使用户的 UI 体验非常快速，因为单击“更新”链接不必进行 AJAX 往返。有人说：

Anthony Eden @aeden 12 月 10 日回复 转推 收藏 · 开启 Web 应用的未来：请求由函数处理，逻辑始终是异步的，并且永远不会在服务器上生成 HTML。

缺点

  • 不适合 SEO（初始页面加载时的非语义无关 UI 元素）
  • 需要一些 Javascript foo（操作元素）

好处 - 响应式 - 更小的信封

趋势似乎正在转向客户端模板，尤其是 HTML5 附加功能（如<canvas>）所展现的强大功能......但如果利用它们需要您依赖您不太熟悉的技术，并且您对 Grails 部分感到更舒服，可能值得从这些开始，然后根据性能和其他问题研究对客户端模板的重构。

于 2011-12-19T06:43:12.680 回答
0

在我看来，第二个选项呈现部分更好，因为如果你得到一个json数据，你应该像设置样式一样操作它，创建元素，设置值和类似的东西，根据需要，在你在 javascript 中获得 ajax 响应之后，但是如果你渲染部分，您可以在该部分之前设计您的视图并保持准备并使用ajax调用导入，因此没有处理响应数据的责任。

于 2011-12-17T18:55:31.350 回答
0

我会说这取决于您在放置时通过电线发送的数据量。如果您正在实现“加载更多”功能，那么您似乎不想花 5 秒钟来加载某些内容。谷歌图片是该功能应该有多快的一个很好的例子。如果您知道您永远不会拥有那么多数据，那么在服务器上渲染部分数据可能会更干净，但如果您的需求发生变化，那么回到第一种方法会很麻烦。所以简而言之，我会说第一种方法允许更多的灾难控制，只要加载更多需要多长时间才能加载大量数据。我想说的是，尽可能减轻服务器的负载也是一种普遍的好习惯，即使它在客户端对开发人员来说有点不方便。

于 2011-12-17T19:15:35.037 回答