区分同一 URL / 路由的请求 HTML 部分布局和完整布局

发布于 2024-10-14 06:02:34 字数 781 浏览 2 评论 0原文

目前我正在为我的 MVC 框架编写路由代码,该框架能够渲染 HTML 部分(视图)。这些部分可以在服务器端或客户端加载(使用 Mootools HTML 请求)。然后,每个页面的布局都是由多个部分构建的。因为我希望它符合 ReST 标准,所以每个 HTML 部分(视图)都映射到定义的 URL 空间中的 URL,如下所示(缩进显示预期的文档结构):

...
/      
  /navigation
  /content
    /profile
      /profile/1
        /profile/1/message/
          /profile/1/message/1
          /profile/1/message/2
...

现在的问题是我希望人们能够访问“ /profile”,然后不显示 HTML 部分,而是显示完整布局。我正在考虑以下内容:

1) 在 URL 中为部分内容创建单独的命名空间/前缀,例如:

  • /profile 表示完整布局
  • /partial/profile 表示部分布局

2) 发送自定义 HTTP 标头以请求部分或部分布局没有自定义 HTTP 标头来请求完整布局。

第一个选项更符合 ReST 标准(缓存友好),但我仍然不确定(这才是真正的问题)其他我可能还不知道的选项。

在开始实施上述解决方案之一之前,我有以下问题:

  1. 我必须有哪些替代方案来区分请求部分布局和完整布局?
  2. 保持每个部分的客户端状态/上下文的最佳实践是什么?

At the moment I am writing the routing code for my MVC framework which is capable of rendering HTML partials (views). These partials can be loaded server-side or client-side (using Mootools HTML request). The layout of every page is then build from multiple partials. As I want it to be ReST compliant, each HTML partial (view) maps to an URL in a defined URL space, as follows (indentation shows the intended document structure):

...
/      
  /navigation
  /content
    /profile
      /profile/1
        /profile/1/message/
          /profile/1/message/1
          /profile/1/message/2
...

Now the problem is that I want people to be able to visit "/profile" and then not being shown the HTML partial, but instead the full layout. I was thinking about the following:

1) Creating a separate namespace / prefix in the URL for partials, for example:

  • /profile for the full layout
  • /partial/profile for the partial

2) Sending a custom HTTP header to request for a partial or no custom HTTP header to request for the full layout.

The first option would be more ReST compliant (cache friendly), but I am still unsure (and that is the real problem) about other options that might still be unknown to me.

Before I start implementing one of the above solutions, I've got the following questions:

  1. What alternatives do I have to distinguish between requesting partials and full layouts?
  2. What are the best practices to keep the client-side state / context of each partial?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

稀香 2024-10-21 06:02:35

当您请求客户端时,服务器将收到额外的标头 HTTP_X_REQUESTED_WITH,其值为 xmlhttprequest。

if(!empty($_SERVER['HTTP_X_REQUESTED_WITH']) && 
   strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest') {
   ....
}

这是一个值得测试的可靠标头,而不是添加自定义类型。

When you request client-side, the server will receive the extra header HTTP_X_REQUESTED_WITH with the value xmlhttprequest.

if(!empty($_SERVER['HTTP_X_REQUESTED_WITH']) && 
   strtolower($_SERVER['HTTP_X_REQUESTED_WITH']) == 'xmlhttprequest') {
   ....
}

This is a reliable header to test for, rather than add a custom type.

你如我软肋 2024-10-21 06:02:35

选项 1 绝对是比选项 2 更好的解决方案。在 RESTful 系统中,我们一直在创建新资源来弥补方法的不足。

创建自定义标头是一个非常糟糕的主意。

Option 1 is definitely a better solution that option 2. In a RESTful system we create new resources all the time to make up for the lack of methods.

Creating a custom header is a really bad idea.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文