1

在过去 3 年左右的时间里，我们一直在增加对 Adob​​e CQ 的使用。我们开始使用 5.4，其中几个开发人员（根据 Adob​​e 顾问的推荐）在 node.js 中存储了几个查找数据“表” /var/site/app。这些被用作诸如邮政编码、站点 ID 等组件的查找存储。

现在我们已经冒险进入 CQ 5.6，并且在我们的发布者实例上访问这些数据时遇到了一些困难。作者工作正常，但是在发布者上，尝试访问数据会导致 404。不久前，我们有一些其他顾问提到将数据存储在 /var 中不是一个好主意，但我不记得背后的原因那。

是否有推荐的位置来存储多个组件、页面或其他对象可以访问的通用查找数据？

提前感谢你的帮助。

4

3 回答 3

2

我不是其背后推理的权威，也许对沿途做出的决策有远见的人可以介入，但据我所知，var 最初是任何临时或派生数据的位置，但不一定是客户面对。

版本控制和一堆其他信息存储在那里，所以它不应该暴露给客户端。

/etc 是通常在调度程序上保持打开的位置，因此如果查找信息属于 SDLC 的一部分，则放置查找信息的逻辑位置在此位置内。

如果查找是可创作的，那么将它放在 /content 目录中会更明智，如果您正在做任何涉及多租户的事情，它将适合重写策略。此外，如果不同的租户正在访问相同的查找数据，即

http://www.mysite.com/mypage.html goes to /content/mysite/mypage and 
http://www.anothersite.com/anotherpage.html goes to /content/anothersite/anotherpage,

重写规则可用于共享位置。例如

www.mysite.com/lookups/postcodes.json /content/lookups/postcodes
www.anothersite.com/lookups/postcodes.json /content/lookups/postcodes

希望这是有道理的。

于 2014-02-11T05:34:02.370 回答
2

我不确定这个问题是否像“你应该把它放在哪里”一样简单。您的组件/页面如何请求此信息？是通过 AJAX 调用吗？如果是这种情况，您真的应该通过将数据生成为 JSON 的 Sling GET Servlet 来访问它。如果您正在谈论通过作者实例对话框访问此数据，则位置应该无关紧要，因为通常您的作者实例是非常开放的。如果您正在谈论在服务器端访问此数据，作为组件渲染的一部分（在 JSP 或其支持类中），那么您绝对不需要将其移动到任何地方，因为 JcrResourceResolver 可以访问它。

我通常不会在 /var 下放置任何东西（它是树的系统部分），但解决方案不是选择另一个任意位置，只是为了让您可以公开它。解决方案是了解您需要在哪里访问该信息，然后针对该情况适当地公开它。有道理？

如果您可以提供有关如何尝试检索数据的更多详细信息，我很乐意提供更多输入。

于 2014-02-12T15:58:12.767 回答
1

/etc是存储与 CQ 的显示部分分开的通用数据的好地方。例如，CQ 用于/etc/blueprints存储有关使用 LiveCopy 的信息。作者和出版商都有一个/etc位置，所以这不是问题。CQ 可以做一些有趣的事情，/var所以我不确定为什么推荐它作为存储位置。

于 2014-02-10T21:50:48.423 回答