在过去3年左右的时间里，我们一直在增加对Adobe CQ的使用。我们开始使用5.4，其中几个开发人员（根据Adobe顾问的推荐）在/var/site/app节点中存储了几个数据查找“表”。这些用作组件的查找存储，例如邮政编码，站点ID等。
现在我们已经进入CQ 5.6，我们在发布商实例上访问这些数据时遇到了一些困难。作者工作正常，但在发布者上，尝试访问数据导致404.前段时间我们有一些其他顾问提到将数据存储在/ var中不是一个好主意，但我不记得背后的原因那。
是否存在用于存储多个组件，页面或其他对象可以访问的通用查找数据的推荐位置？
提前感谢您的协助。
答案 0 :(得分：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,
重写规则可用于共享位置。 e.g。
www.mysite.com/lookups/postcodes.json /content/lookups/postcodes
www.anothersite.com/lookups/postcodes.json /content/lookups/postcodes
希望这是有道理的。
答案 1 :(得分：2)
我不确定这个问题就像“你应该把它放在哪里”一样简单。您的组件/页面如何请求此信息？是通过AJAX调用吗？如果是这种情况，您应该通过Sling GET Servlet访问它，该Servlet将数据生成为JSON。如果您正在讨论通过作者实例对话框访问此数据，则位置无关紧要，因为通常您的作者实例非常开放。如果您正在谈论访问此数据服务器端，作为组件呈现的一部分（在JSP或其支持类中），那么您绝对不需要将其移动到任何位置，因为JcrResourceResolver可以访问它。
我通常不会在/ var下放任何东西（它是树的系统部分），但解决方案不是选择另一个任意位置，只是这样你就可以暴露它。解决方案是了解您需要访问该信息的位置，然后针对该情况进行适当的公开。有意义吗？
如果您能提供有关如何检索数据的详细信息，我很乐意提供更多输入。
答案 2 :(得分：1)
/etc是存储与CQ的显示部分分开的通用数据的好地方。例如，CQ使用/etc/blueprints来存储有关使用LiveCopy的信息。作者和发布商都有一个/etc位置，因此这不是问题。 CQ可以对/var做一些有趣的事情，所以我不确定为什么建议将它作为存储位置。