ECM의 범위가 너무 커서 완전히 일반적인 지침을 제시하는 것이 매우 어렵습니다. 해결해야 할 유스 케이스를 고수하고 최상의 솔루션을 찾아야합니다. RM은 Alfresco 위에 레코드 관리 솔루션을 구현하는 방법의 좋은 예이지만, 웹 게시 프로세스를 구현할 때는 전혀 쓸모가 없습니다. WCM QS을 시작점으로보고 싶습니다.
전체 API에서 Alfresco는 개발자에게 제공하며, 내부 특성은 궁극적으로 언제 사용하는지 이해할 수있는 최상의 리소스입니다. 내가 (적어도 그들 사이에서 가장 중요한) 의미를 만들 수 있는지 보자. 당신이 항상 알 프레스코 프로젝트를 구현 시작해야하는 곳이다
콘텐츠 형식
. 구현해야하는 문서 처리에 대한 심층적 인 도메인 지식을 가진 사람과 긴밀히 협력하고 다양한 문서 수명주기에 대한 루트 요소를 정의해야합니다. Alfresco에서는 주어진 노드에 단 하나의 콘텐츠 유형 만 지정해야합니다. 이는 컨텐츠 작성시에 이루어지며 컨텐츠 라이프 사이클에 따라 자주 변경되지는 않습니다. 따라서 콘텐츠 유형은 급격히 다른 라이프 사이클 (예 : cm:document 및 ws:article)으로 콘텐츠 항목을 식별하는 데 일반적으로 사용되며 콘텐츠 형식을 정의하면 전체 문서 수명주기 동안 사용되거나 유용하게 사용될 기본 메타 데이터 속성을 추출하는 것을 의미합니다.
양태
콘텐츠 유형은 기본적으로 정적 문서 수직 분류 및 농축 동안이 양태는 동적 사촌. 콘텐트 유형과는 달리, 콘텐트 노드에 대해 거의 없으며 파괴적인 영향을 미치지 않으면 서 양상을 동적으로 적용하거나 제거 할 수 있습니다. 더 많은 메타 데이터로 문서를 풍부하게하거나 풍부하게 만들 수 없으며 내용 유형에 관계없이 항목에 적용 할 수 있습니다. 이러한 특성은 Alfresco 콘텐츠 모델의 가장 융통성있는 기능인 측면을 가능하게합니다.이를 통해 콘텐츠를 표시하거나 다양한 콘텐츠 수명주기 (예 : cm:versionable, rma:filePlanComponent)에서 공유되는 작업을 활성화/비활성화 할 수 있습니다. 본질적으로 측면은 여러 가지 고유 한 라이프 사이클 또는 라이프 사이클 단계에서 발생하는 교차 절단 개념을 처리하기위한 것입니다.
행동
여기에 우리는 당신의 프레스코 솔루션에 논리를 추가하는 방법에 대한 개요를 시작합니다. 비헤이비어는 트리거가 [유형/측면, 정책] 쌍 (예 : [cm:versionable, onCreateNode])으로 정의되는 특정 트리거에 의해 실행되는 자동 계산입니다. 일반적으로 트리거를 실행하는 이벤트와 동일한 트랜잭션 내에서 실행됩니다. 실행 순서에 대한 보장이 없으며 조정 또는 조정이 없습니다. 따라서 콘텐츠 라이프 사이클의 필수 요소가되어야하지만 형식화 된 프로세스의 일부는 아닌 자동 콘텐츠 생성 또는 처리 (예 : 축소판 만들기 또는 일부 메타 데이터 업데이트)에 이상적입니다.
이들은 정상적인 작업이나 워크 플로에 대한 보조 또는 보조 작업입니다. Java 코딩이 필요하므로 솔루션의 다소 고정 된 부분을 형성합니다. 일반적으로 콘텐츠 모델링 단계를 마친 직후와 워크 플로 디자인을 시작하기 전에 동작을 식별하고 디자인합니다. 행동에
유사
규칙은 규칙은 특정 이벤트에 트리거,하지만 그들은 훨씬 더 일반적이고 역동적 인 그들보다 더있어. 규칙 만 폴더에서 구성 할 수 있으며 런타임에 폴더 내에서 발생하는 이벤트에 바인딩 할 수 있습니다. 따라서 콘텐츠 저장소에서 콘텐츠를 처리 할 때 부작용이 발생하는 특정 버킷을 만드는 것이 이상적입니다 (예 : 콘텐츠가 특정 폴더에 추가 될 때마다 이메일 보내기). 그것들은 폴더 내의 숨겨진 노드로 구현되므로, 필요한 조각을 사용할 수 있다면 이론적으로 다른 Alfresco 구현에서 빌릴 수 있습니다.
일반적으로 논리적 부분이 여러 가지 유형의 내용에 적용되지만 영향을받는 유형의 항목 모두는 아니며 저장소의 하위 분기 내에 영향을받는 모든 내용 노드를 저장할 수있는 경우에만 사용됩니다 . 이러한 제약이 심해질지라도 규칙은 매우 유용한 도구로 나타납니다 (예 :/이미지의 MIME 유형이 image/png 인 모든 PNG 문서의 미리보기 이미지 생성).
작업
작업은 필요에 따라 노드에 대해 호출 할 수있는 논리의 조각을 번들로 제공됩니다. 규칙을 구성하는 요소이며 워크 플로 내에서 자주 사용됩니다 (예 : 이메일 보내기). 또한 사용자가 응용 프로그램의 사용 가능한 기능에 직접 노출 될 수 있도록 UI 구성 요소/단추에 직접 바인딩하는 것이 편리합니다. 일반적으로 워크 플로우, 규칙 및/또는 직접적인 사용자 상호 작용과 같은 다른 상황에서 동일한 로직을 재사용해야 할 필요가있을 때 액션을 개발하게됩니다.
워크 플로우
이것은 아마도 문서 관리의 핵심 사업 : 워크 플로우는 기본적으로 인간의 알고리즘을 구현 단계의 정의 된 순서를 통해 사용자를 안내하는 통합 된 프로세스를 구축 할 수 있습니다. 워크 플로를 사용하면 사용자 지정 코드를 작성할 수 있지만 유지 관리를 위해 코드를 실행하기 위해 워크 플로 자체에서 필요로하는 최소한의 코드로 제한하고보다 복잡한 작업을 작업 또는 스크립트에 외부화하려는 경우가 있습니다.
문서 관리를 수행하는 경우 워크 플로 디자인 및 구현은 콘텐츠 모델링 직후에 시작될 수 있으며 액세서리 작업 및 스크립트와 같은 몇 가지 다른 개발 활동이 생성 될 수 있습니다. 코드 기능이 완료되고 UI상의 모든 무한 변경 요청 또는 남은 부분을 만지작 거리며 시작합니다 :-)
규칙을 가장 많이 신경 쓰는 점은 저장소 경로 (company_home/테스트/테스트 2). 그것은 당신이 물건을 내보낼 때 문제를 가져옵니다. 프로그래밍 방식으로 선언하고 앰프 패킷이로드 될 때 적용 할 수 있습니까? 마지막으로 나는 내 소프트웨어가 앰프에 완벽하게 압축되어 있고 앰플리파이어를 사용할 준비가되었을 때 (어쩌면 사용자 정의 유형 사이트를 생성하기 위해 단지 한 번의 클릭으로) 필요할 것입니다. –
가져 오기 [UUID 바인딩] (http://wiki.alfresco.com/wiki/ACP#Import_UUID_Bindings)이이를 처리하기에 충분하지 않습니까? – skuro
예, AMP [부트 스트랩 프로세스] (http://wiki.alfresco.com/wiki/Advanced_AMP_Development)의 일부로 규칙을 적용 할 수 있습니다. – skuro