Adobe CQ에서 조회 데이터를 저장하는 위치

Question

지난 3 년 동안 우리는 Adobe CQ 사용을 늘려 왔습니다. 우리는 5.4를 사용하여 여러 개발자 (Adobe 컨설턴트의 추천에 따라)가 여러 가지 "테이블"의 데이터를/var/node에 저장하는 것으로 시작했습니다. 이들은 우편 번호, 사이트 ID 등과 같은 구성 요소의 조회점으로 사용되었습니다.

이제 우리는 CQ 5.6을 모험 중이며 우리 게시자 인스턴스에서이 데이터에 액세스하는 데 어려움을 겪고 있습니다. 저자는 잘 작동하지만 게시자의 경우 데이터에 액세스하려고 시도하면 404가됩니다. 일부 컨설턴트는/var에 데이터를 저장하는 것이 좋지 않다고 말하면서 잠시 뒤에 추론의 배경을 기억하지 않습니다 그.

여러 구성 요소, 페이지 또는 다른 개체에서 액세스 할 수있는 일반 조회 데이터를 저장하기위한 권장 위치가 있습니까?

미리 도움을 주셔서 감사합니다.

Answer 1

나는 그 뒤에있는 추론에 대한 권위자가 아닙니다. 길을 따라 내려진 결정에 대한 비전을 가진 사람이 들어갈 수 있지만, 내가 알 수있는 것으로부터, 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 

희망이 있습니다.

Answer 2

/etc은 CQ의 디스플레이 부분과 별개의 일반 데이터를 저장하기에 좋습니다. 예를 들어 CQ는 /etc/blueprints을 사용하여 LiveCopy를 사용하는 것에 대한 정보를 저장합니다. 작성자와 게시자 모두 /etc 위치이므로 문제가되지 않습니다. CQ는 /var으로 재미있는 일을 할 수 있으므로 저장 위치로 추천 된 이유가 확실하지 않습니다.

Answer 3

나는이 질문을 "어디에 넣어야합니까?"라고 간단하지 않습니다. 구성 요소/페이지에서이 정보를 요청하는 방법은 무엇입니까? AJAX 통화를 통한 것입니까? 그렇다면 JSON으로 데이터를 생성하는 Sling GET Servlet을 통해 실제로 액세스해야합니다. 제작자 인스턴스 대화 상자를 통해이 데이터에 액세스하는 것에 대해 이야기하는 경우 일반적으로 작성자 인스턴스가 꽤 열려 있기 때문에 위치는 중요하지 않습니다. 이 데이터 서버 측에 액세스하는 것에 대해 이야기하고 있다면 (JcrResourceResolver에 액세스 할 수 있기 때문에) JSP 또는 Backing 클래스 내에서 구성 요소 렌더링의 일부로 확실히 이동할 필요가 없습니다.

저는 일반적으로/var (시스템의 일부분)에 아무것도 넣지 않지만 솔루션은 다른 임의의 위치를 ​​선택하지 않기 때문에 노출시킬 수 있습니다. 해결책은 해당 정보에 액세스해야하는 위치를 파악한 다음 해당 정보를 적절히 노출하는 것입니다. 이해가 되니?

데이터를 검색하는 방법에 대한 자세한 정보를 제공 할 수 있다면 더 많은 정보를 제공해 드리겠습니다.