渐进增强 - JavaScript 关闭时该怎么办？
我理解什么是渐进增强，但我只是对实际实现它的一些细节感到模糊。当然，这可能是因为我以错误的方式看待它。让我尝试用一个假设的
ASP.NET MVC 站点来解释我的困难。我有一个带有选项卡式导航的视图。每个选项卡对应一个电影类别/流派，其中显示该类别中电影的 5-10 个链接。电影数据是通过Netflix的Odata获取的。
我最初的想法是，当单击每个选项卡时，使用 Ajax 从正确的 OData GET 请求中提取并解析 JSON。我如何提供它的非 JavaScript 版本？有可能吗？
对于不需要 JSON 的简单请求（例如，让用户登录系统），我了解如何简单地设置 cookie 并根据它动态更改页面以反映更改。但是如果我需要返回并解析 JSON 怎么办？我如何提供替代方案？
I understand what progressive enhancement is, I'm just fuzzy on some of the details in actually pulling it off. Of course, that could be because I'm looking at it in the wrong way. Let me try to explain my difficulty with a hypothetical:
ASP.NET MVC site. I have a view that has tabbed navigation. Each tab is for a movie category/genre which displays 5-10 links to movies in that category. The movie data is obtained through Netflix's Odata.
My initial thought is to use Ajax to pull and parse the JSON from the proper OData GET requests when each tab is clicked. How would I provide a non-JavaScript version of that? Is it even possible?
For simpler requests where JSON isn't necessary - like, say, having a user log into the system - I see how I could simply set a cookie and dynamically change the page based on it to reflect the change. But what if I need to return and parse JSON? How do I provide an alternative?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
渐进式增强的要求是，您的服务器端必须完全能够生成出现在所有页面中的每一个 HTML。这是显而易见的，因为否则（如果 JS 关闭）应用程序中将没有任何部分能够执行上述渲染。
由于服务器端必须知道如何渲染所有内容，因此根据服务器提供的 JSON 响应在客户端生成内容（DOM 元素/HTML）没有多大意义。为什么要重复自己呢？
这给我们带来了一个合乎逻辑的结论：在客户端进行动态更新时，您需要从服务器获取现成的 HTML（因为渲染逻辑就在那里）并将其插入到适当的 DOM 中。然后，您可以自由地使用 jQuery 处理新插入的元素并根据需要增强它们。
因此，忘记在客户端解析 JSON，否则您将无法进行渐进式增强。如果您想调用第三方，请让服务器作为您的中介：使用所有必要的信息调用服务器，以便服务器调用第三方并获取现成的 HTML。
如果您这样做，那么服务器当然可以毫无问题地提供您网站上所有内容的非 JS 版本。实现了完全不依赖 JS。
The deal with progressive enhancement is that your server side must be fully capable of generating every last bit of HTML that appears in all of your pages. This is obvious, since otherwise (if JS is turned off) there will be no part of your application capable of doing said rendering.
Since the server side must know how to render everything, it doesn't make much sense to generate things (DOM elements/HTML) on the client side from JSON responses the server gives you. Why repeat yourself?
This brings us to the logical conclusion that when doing dynamic updates on the client, you need to get ready-made HTML from the server (since the rendering logic is over there) and insert it into the DOM as appropriate. You are then free to work on the newly inserted elements with jQuery and enhance them all you want.
So -- forget about parsing JSON on the client, otherwise you 're locking yourself out of progressive enhancement. If you want to call a third party, have the server be your intermediary: call the server with all the necessary information for it to call the third party and get ready-made HTML back.
If you do this, then the server can of course provide non-JS versions of everything on your site with no problem. Total non-reliance on JS achieved.
根据定义（JavaScript 对象表示法），没有 JS 就没有 JSON。没有 JS，您将无法进行 AJAX 调用。您的页面将按原样呈现，就像老式网站一样。
如果您需要逐步执行此操作，则必须在服务器端调用 odata 服务，并向 viewdata 或视图模型中的站点提供 .net 对象，并让您的视图/部分渲染它。
在 ASP.Net MVC 操作中，通过控制器提供的 httpcontext 将在此路径上有一个属性：
this.HttpContext.Request.IsAjaxRequest()，可用于测试是否要返回视图或者只是 json 数据，或者您想要的任何类型的 ActionResult。对于构建渐进增强风格的网站来说，这可以极大地节省时间。There is no JSON without JS, by definition (JavaScript Object Notation). Without JS you won't make AJAX calls. Your pages will render as is, just like oldschool sites.
If you need to do this progressively, you will have to call the odata service server-side, and provide .net objects to the site in viewdata, or your viewmodel, and have your views/partials render it.
In ASP.Net MVC actions, the httpcontext available via the controller will have a property on this path:
this.HttpContext.Request.IsAjaxRequest()and can be used to test whether you want to return a view or just json data, or whatever type of ActionResult you want. This can be an excellent timesaver for building progressive enhancement style sites.