Portal 內容轉置的探討

　　此可分為兩部份來看，首先是對原內容儲存庫中結構性內容，即有定義內容型態的部份，要定義對應的新系統Content type, 且要加上新系統所需要的考量。而對非結構性內容，亦即未定義內容型態者，則視客戶實際需求來決定，是否要在新系統中定義對應的新內容型態，而所欠缺必要的Content attribute，則要由原內容中以程式(可行的話)或以人工(極耗工)找出來補足。

　　還有非結構性內容的Layout，通常與內容交雜在一起的且難以分離，新系統能否正常顯示，也必須注意。此外，Style與內容是否有以CSS分離，也必須留意才行，否則在新系統的顯示會變得很不協調！

　　因此，對原結構性內容部份，需要定義新系統的內容型態，而無結構性內容部份，則還需要與客戶溝通，確認是否有某些類型內容需要轉換為結構性或混合性(兩者都兼而有之)，最好是全部都不需要轉換，或是另案加以處理，否則會是極大的人力負荷！就算是全部都先不轉換，為過無障礙檢測，所有內容不分結構或非結構者，仍然會需要補足內容中許多被包含的多媒體物件或檔案的Metadata(必要的)，因為原系統中這部份極可能是欠缺的，至少非結構性內容很可能沒有。

　　綜合以上所述，要進行內容轉換所需進行的處理作業應該就顯而易見了：

1. 要能區分原系統中結構性與非結構性內容。
2. 識別出原系統所有內容已有之Metadata, 並建立與新系統Metadata的轉換對應規則。對於新系統為必要而原系統欠缺的Metadata，須提供補足的方法。
3. 在新系統中定義所需的內容型態，Metadata及資料結構。
4. 對結構性內容建立顯示時套版所需要的版型。
5. 對所有內容可以程式自動轉換的部份，撰寫轉換程式並進行轉換，應在此設法補足所欠缺的必要Metadata，以減少人力負荷！
6. 對無法以程式自動補足的部分，以人力進行補足！
7. 測試在新系統中對所轉換內容，是否可以正常運作(CRUD及全文檢索)

　　以上僅就CMS中的內容轉置來討探，但會以內容儲存庫來存取內容者，並不局限於CMS，若要考量到所有儲存庫內容的轉置時，則勢必要做更深入且廣泛的考量才行。其實對客戶而言，重要的是我們能否提出多個完備且可行的內容轉換方案，並詳列所有重要的決策點，再由使用者討論決定採取那個方案進行，再預估內容轉置時程才有意義。

交通部OA專案Porlet平台調校 - 頁面顯示效能不佳

問題及現況描述：

　　現有Apache JetSpeed portlet平台頁面顯示效能不佳。雖然影響效能的因素很多，但其中Portlet的顯示方式，給使用者的感覺乃極重要因素之一。而現行做法是以synchronous server-side aggregated方式來顯示頁面，顯示所需時間為所有區塊內容產生及組合時間的總和，此乃傳統Portal平台效能無法有效提升的重要原因。
　　雖然JetSpeed 2.0也有提供asynchronous server-side aggregated方式，顯示所需時間為最大區塊內容產生及組合時間的總和，應可明顯地加速頁面的顯示速度。但可能是對原JetSpeed平台修改所造成的影響，經實際地測試之後發現，並未如預期般地，各區塊內容以非同步方式產生。而且由於整個頁面的顯示時間，會受到最慢區塊內容產生的影響，所以此種方式還是無法令使用者有較好的感受。
　　專案初期所使用為Apache JetSpeed 2.0，並未提供client-side aggregated (名為desktop)顯示功能，但Apache JetSpeed 2.1已具備此功能。此方式是將各區塊內容的套版，改在client-side進行作業。而server-side產生各區塊內容的方式也有兩種: PortletAggregator及PageAggregator(預設)。具推測兩者的差異，應在於server-side中各區塊內容產生，是以同步或非同步方式進行，但client-side的套版作業將會有所不同。對使用者感受而言最佳做法，應該是以非同步的方式來產生各區塊內容(Desktop+PortletAggregator)。
　　雖然平台後來也轉換為Apache jetSpeed 2.1，但經實測之後發現原平台Desktop功能是可以正確運作的，而修改後的平台卻無法運作。觀察顯示的運作模式後發現，此方式在每次submit時，還是會重新顯示整個頁面，但由於各區塊內容乃以AJAX方式套入版型之中，所以對使用者的感受而言會較可接受。當然，最好的方式是各Portlet區塊的submit，全部都改以AJAX方式處理，如此將可達到最佳顯示性能，但Portlet的開發方式必須配合才可達成此一目的。

解決方案：

1. 解決修改後的Apache JetSpeed 2.1 portlet平台，無法使用Desktop及非同步區塊內容產生功能的問題。
2. 改寫用於主頁面所有Portlet，將顯示及submit全部改以非同步背景方式進行；但此作法乃將系統面的問題，由應用面程式來解決的不良方案。
3. 以Filter欄截所有的請求及回應，將Portlet的顯示及submit，全部改以非同步背景方式進行，但可行性及難度未經實際驗證及評估過。

方案１的初步嘗試：

　　比較原平台及修改後平台的全部原始碼，已找出原始碼差異之所在，由於本人並非原修改者，且未經實際運作差異之比較，故短時間內尚無法理解所有修改處的原由，雖然部份修改已可約略瞭解其修改之目的，但未經原修改者或實際運用差異的比較來確認，終究無法完全瞭解修改之目的。經歷此次事件的過程，本人有以下幾點想法：

1. 對於專案開發過程所做的任何變動，不論是關於應用面或系統面的，都必須精確地紀錄其原始及變更之目的：雖然本案有用SVN(Subversion)來進行版本控制，但卻未對修改前後的JetSpeed 2.0及2.1平台原始碼進行版本控制，以及變動歷程的紀錄，也未對所修改的部份加上詳細的註解說明，如此將會造成將來接手平台維護者及此方案所面臨的窘境。
2. 系統修改之前應先Refactoring：將要修改的部份隔離，以增加系統原始碼的可讀性。
3. 切莫因為不瞭解原系統設計架構或求快速達到目的，而變更原系統設計架構：原JetSpeed平台的認證及授權功能，是以標準的JAAS架構來達成。此標準的設計目的即在於，希望應用程式與平台間可以透過標準的方式來進行安全性的整合。此次平台修改卻放棄以此標準做法，而走捷徑來進行認證及授權的整合。

方案１的接續做法：

1. 先分兩部份一起進行：Ａ.找出造成影響的被修改模組；Ｂ.瞭解每個修改的目的。
2. 針對造成影響的被修改模組進行改造，期使原模組功能及再修改之目的皆可達成。

台北市政府入口網內容轉置的做法

現有情況：

　　以RDB及File System做為內容儲存方式，以RDB為主而File System為輔。有General及Adevenced兩種版型，其中General是後來加入較為結構性之版型，但用此種版型的網站並不多，原來的Adevenced版型是以在Template中安插特殊註解符號做為代換之位置，而使用者輸入之內容則直接以HTML形式編輯，再存放為靜態之檔案，顯示所代換引入之項目，除節點靜態檔案內容外，亦包括動態生成之功能表及其他相關內容。存放內容的HTML檔，因為使用者可以任意編輯其內容，故而Layout和Style會與內容以任意方式組合，將難以程式來自動分離內容與格式，只能以人工方式進行分離作業，初期應該可以保持原狀即可，但系統必須能區分新舊內容，以免顯示會有問題！

內容及Metadata轉置處理流程：

1. 瞭解JCR定義Schema的方式，並先定義資料結構
2. 瞭解以標準XML組織內容及Metadata的方式
3. 瞭解現有內容及Metadata的組成結構
4. 撰寫將Adevenced的內容轉換為JCR滙出入XML格式的程式, 應儘力設法以自動方式補足所需之Metadata
5. 撰寫將General內容轉換為JCR滙出入XML格式的程式, 應儘力設法以自動方式補足所需之Metadata
6. 滙入步驟4,5產生的XML至JackRabbit中，先試行少量內容待測試無誤再進行全面性轉置，轉換後應驗證是否能正常顯示及編輯
7. 最耗費人力的部份，則在於為好幾百個網站進行型版的客製，最好能教導各網站管理人員自行客製，部份執行有問題的網站再加以輔導，可能需要市府政令宣達方式來要求各單位配合！
8. 另外，對原有內容先不要補足欠缺的Metadata(含研考會要求的)，若有單位被要求要檢驗時，再協助該單位進行Metadata的補足，但系統必須能區分無必要Mettadata的內容，以免顯示Metadata會有問題！

ps. 對於所有轉置的內容資料，新系統應該提供能涵蓋原系統資料編輯的功能，否則所轉置的資料將不可再被編輯修改！