0

环境： Concrete5 解析 URL 以找到页面的控制器 - 或工具文件，它没有视图 - 并呈现它的视图。这有点简单，但这是要点。

因为 Concrete5 拥有如此漂亮的架构来处理大量内容，所以我想将其用作一种后端机制来为用主干编写的 Web 应用程序提供动力。Backbone 需要一个 RESTful 实现，我已经看到 Slim 实现了它——一个基于 PHP 的 RESTful api。

冲突： 因为 Concrete5 解析 URL（以发现页面的控制器 [呈现视图] 或工具文件 [不呈现视图]）它与 Slim 的 REST 实现冲突。这部分是真的……

这部分只是相信： Slim 的 URL 是伪造的，仅用于进行 Backbone 在成功时使用的 ajax 调用 (REST)。浏览器被阻止执行其默认操作 - 这意味着一旦您在选择页面上，与 Concrete5 没有冲突。

问题：

1）。那么答案仅仅是创建一个single_page 而根本不呈现视图吗？
2）。一旦“未呈现”，我可以简单地继续上述信念吗？
3）。还是我会遇到比我意识到的更多的冲突？

当然，有一种方法可以让 C5 拥有一个页面（通过将全局“C5_ENVIRONMENT_ONLY”变量设置为“true”而不是整个站点）来使用 RESTful api。

有没有其他人在其他 CMS / Backbone 项目中做过类似的事情？

TIA

4

1 回答 1

1

您是否将 C5 站点中管理的内容提供给主干前端应用程序？还是这个应用程序与 C5 内容不同？如果前端应用程序与 C5 内容不同，那么我将完全绕过 C5 这条路径并将应用程序放在那里做自己的事情（只有在实际请求的 URL 处不存在页面时才调用 C5 的路由器） .

如果内容由 C5 管理，那么我认为 Slim/Backbone 和 C5 的不同路由系统不可能一起工作。在这种情况下，我能想到的唯一解决方案是将主干应用程序作为 Concrete5 工具文件提供服务，但在 htaccess 文件中使用重写规则来欺骗 c5 认为对主干应用程序的所有请求都将发送到正在服务的一个工具文件它...然后破解骨干网/超薄路由器以识别那些 htaccess 修改（例如，htaccess 将请求转换为某个路径以作为查询字符串参数，然后您的骨干网/超薄应用程序将这些查询字符串参数放回框架正在寻找 URL 的任何位置路径组件）。

无论哪种方式，这将是颈部的全部疼痛，而且很可能不值得麻烦。

于 2012-08-14T16:01:26.040 回答