For the past 3 years or so, we have been increasing our usage of Adobe CQ. We started out using 5.4 where several developers (on the recommendation of Adobe Consultants) stored several lookup "tables" of data in /var/site/app node. These were used as lookup stores for components such as ZIP codes, site IDs, etc.
Now we have ventured into CQ 5.6 and we are having some difficulty accessing this data on our publisher instance. The author works fine but when on the publisher,attempts to access the data result in a 404. A while back we had some other consultants mention that storing the data in /var was not a good idea but I don't recall the reasoning behind that.
Is there a recommended location for storing generic lookup data that several components, pages, or other objects will have access to?
Thanks in advance for your assistance.
I am not an authority on the reasoning behind it, perhaps a person with vision to the decisions made along the way can step in, but from what I can tell, var was originally a location for any temporary or derived data, but not necessarily customer facing.
Versioning, and a stack of other information is stored there, so it should not be exposed to clients.
/etc is the location that has been left open on the dispatcher generally, so the logical place to put lookup info if it belongs as part of the SDLC, is within this location.
If the lookups were to be authorable, it would be more wise to place it in the /content directory, which if you're doing anything that involves multitenancy will fit in with the rewrite strategy. Furthermore, if different tenants are accessing the same lookup data, ie,
http://www.mysite.com/mypage.html goes to /content/mysite/mypage and
http://www.anothersite.com/anotherpage.html goes to /content/anothersite/anotherpage,
a rewrite rule can be used for the shared location. e.g.
www.mysite.com/lookups/postcodes.json /content/lookups/postcodes
www.anothersite.com/lookups/postcodes.json /content/lookups/postcodes
Hope that makes sense.