Alfresco - 自定義文檔生命週期的最佳實踐（Java？）

Question

在與倫敦DevCon的一些人交談之後，在查看記錄管理源代碼之後，我注意到實際上沒有如何實現自定義文檔生命週期的好例子。 我知道有一些規則和內容建模的例子，甚至是工作流程，但是這些解決方案不能真正用於實施像記錄管理這樣更嚴肅的事情。

我想知道的是如何有效地映射到Alfresco的Java解決方案（我有更多的面向對象和Java比Alfresco的經驗）。什麼應該定義爲Java類，什麼應該是內容模型中的類型/方面。何時支持超出規則的行爲以及何時實際使用工作流程。在我使用工作流實現文檔生命週期的前幾個項目中，我在工作流節點中編寫了很多bussines/domain邏輯 - 作爲動作（JS）。我後來發現，這是很難維護，因爲你有一些代碼在工作流中，一些在存儲庫作爲腳本（數據字典/腳本）一些Java，...

是記錄管理的好例子，開始學習並參閱實施完整文檔生命週期的一些最佳實踐？有沒有其他資源？

我正在爲如何在java中實現完整的生命週期以及如何「集中」bussines/domain邏輯而苦苦掙扎。

Answer 1

ECM的範圍很大，因此很難提出完全一般的指導方針：您確實需要堅持必須解決的用例並找到最佳解決方案。 RM是如何在Alfresco上實施記錄管理解決方案的一個很好的例子，但在實現網絡發佈流程時絕對沒有用，因爲WCM QS就是您想要看的起點。

對於Alfresco爲開發人員提供的整個API，他們的內在特徵最終是理解何時使用它們的最佳資源。讓我們看看我能否理解它們（至少是最重要的）。

內容類型

這是你總是需要開始實施的露天項目。您需要與熟悉需要實施的文檔處理深層領域知識的人員密切合作，併爲不同的文檔生命週期定義根元素。在Alfresco中，您必須將一個且僅有的一種內容類型分配給給定的節點。這是在內容創建時完成的，並且在內容生命週期中不會經常更改。因此，內容類型通常用於識別具有截然不同的生命週期的內容項目（例如，cm:document和ws:article），並且定義內容類型意味着提取將在整個文檔生命週期中使用或有用的基本元數據屬性。

方面

雖然內容類型基本上都是靜態的垂直分類和文件富集，方面是其動態表兄弟。與內容類型相反，您可以動態應用或刪除方面，而對內容節點的影響較小或無破壞性。他們可以或不可以使用更多元數據來豐富文檔，並且可以將其應用於項目，而不管其內容類型。這些特性使得這些方面可能成爲Alfresco內容模型最靈活的特性：您可以使用它們來標記內容或啓用/禁用在不同內容生命週期中共享的操作（例如cm:versionable,rma:filePlanComponent）。就本質而言，方面旨在處理在幾個不同的生命週期或生命週期步驟中出現的橫切概念。

行爲

在這裏，我們開始的如何在露天解決方案添加邏輯的概述。行爲是由特定觸發器觸發的自動計算，其中觸發器定義爲[類型/方面，策略]對（例如[cm:versionable，onCreateNode]）。它們通常在觸發觸發器的事件的同一事務中執行，不能保證執行的順序，也沒有協調或編排。這使得它們非常適合自動內容生成或處理（例如，創建縮略圖或更新一些元數據），這些內容需要成爲內容生命週期的組成部分，但這些並不是形式化過程的嚴格組成部分。

對於正常操作或工作流程，它們是相當輔助或補充的操作。它們需要Java編碼，因此形成了解決方案中相當固定的一部分。您通常在完成內容建模階段並開始設計工作流程之前確定並設計行爲。

規則

類似行爲，規則是在特定事件觸發，但他們是一個比他們更通用的和動態的。您可以在運行時僅在文件夾上配置規則，並將它們綁定到文件夾內發生的事件。這使得他們理想的在您的內容存儲庫中創建特殊的存儲桶（例如，每當將內容添加到特定文件夾時發送電子郵件），其中在處理內容中的副作用時發生。它們被實現爲文件夾內的隱藏節點，因此成爲導出的不可分割的一部分：理論上你可以在不同的Alfresco實現中借用它們，前提是所需的部分可用。

它們通常在邏輯應用於多種不同類型的內容時使用，但可能不是受影響類型的所有項目，並且僅當您可以將所有受影響的內容節點存儲在存儲庫的子分支內時。即使這樣的約束聽起來很重，規則也是一個非常方便的工具（例如，在/ images中爲mime類型image/png生成所有png文檔的縮略圖）。

操作

操作被捆綁邏輯塊，可以針對按需節點被調用。它們是規則的基石，常用於工作流程中（例如發送電子郵件）。它們也很方便直接綁定到UI組件/按鈕，以便讓用戶可以直接看到應用程序的可用功能。當您需要（需要啓用）時，通常最終會開發一個動作，以便在不同的環境中重用相同的邏輯塊，例如工作流，規則和/或直接用戶交互。

工作流程

這可能是文檔管理的核心業務：工作流允許你建立一個協調的過程中，通過定義的一系列步驟引導用戶，基本實現人的算法。工作流程允許您編寫自定義代碼，但爲了可維護性，您可能希望將這些代碼限制在工作流本身需要執行的最低限度，並將更復雜的操作外部化爲操作或腳本。

如果您正在進行文檔管理，工作流的設計和實施可以在內容建模之後開始，可能會產生其他幾項開發活動，例如配件操作和腳本，並且它們可能持續到您致電代碼功能完成，並開始擺弄UI上的所有無限更改請求或剩菜:-)