修改 Community Server 的 blog editor
摘要提示
- 動機：作者每次換 blog 平台都先改編輯器，以支援貼圖與表情符號。
- 使用元件：Community Server 採用 FreeTextBox（FTB）作為底層編輯器。
- 架構問題：CS 並非直接內嵌 FTB，而是加了一層自家的 Editor Wrapper。
- 原始碼缺漏：CS 官方提供的原始碼缺少 Editor Wrapper 這一塊。
- 整合困難：因少了 Wrapper 原始碼，無法將自訂工具列整合進 FTB 既有工具列。
- 顯示效果：新增的工具列只能獨立擺在畫面上方，與原本介面略顯不一。
- 功能遺憾：FTB 還有許多好用工具列可啟用，但受限於架構無法完整利用。
- 作者感受：雖能達成基本需求，整體仍有「可惜」與不夠協調的遺憾。
全文重點
作者描述在 Community Server（CS）平台上改造部落格編輯器的經驗與限制。其一貫目標是讓編輯器能方便插入圖片與表情符號；CS 底層採用的 FreeTextBox（FTB）本身並不難擴充，理論上能開啟更多實用的工具列功能。然而，CS 在 FTB 之上加了一層自有的 Editor Wrapper，真正被嵌入與呼叫的是這個包裝層，而非直接使用 FTB。麻煩在於官方釋出的 CS 原始碼偏偏缺少了這個 Wrapper 的部分，使得想要從內部擴充或更動編輯器行為、將自訂按鈕與功能無縫加入 FTB 工具列都變得困難。
在缺乏關鍵包裝層原始碼的情況下，作者只能退而求其次，將新增功能以額外工具列的形式堆疊在頁面上方，雖能達成貼圖與貼表情等核心需求，但無法把新功能優雅地整合進 FTB 既有工具列，導致整體介面顯得格格不入。作者感嘆，如果能直接控制 FTB 或取得完整的 Wrapper 原始碼，就能開啟更多 FTB 原生工具並維持一致的操作體驗；現在的結果雖可用，卻難免留下「好用功能打不開、介面不協調」的可惜。
段落重點
改編輯器的動機與慣例
作者每次更換部落格系統的首要任務，都是先改編輯器，目標明確：要能快速貼圖與插入表情符號，改善日常發文效率與表達力。這次在 Community Server 上延續同一慣例，著手強化編輯器體驗，並以此作為評估平台易用性的關鍵面向。動機來自實務需求與既有寫作流程，並非單純玩票性質。
CS 的技術架構與原始碼缺漏
Community Server 雖以 FreeTextBox（FTB）為底，但並不是直接嵌入使用；中間多了一層 CS 自行實作的 Editor Wrapper。理論上，這種包裝能提供一致的接入與擴充點，但實務上作者遇到的最大障礙，是官方釋出的原始碼缺少這個 Wrapper，導致無法從正規管道改寫或擴充包裝層的行為。因為改不到核心包裝，很多想直接在 FTB 工具列上新增的功能就無法順暢整合，只能改從外部繞道。
實作結果與限制、遺憾
在無法更動 Wrapper 的前提下，作者以額外工具列的方式實現了貼圖與貼表情等基本功能，但這些新按鈕不得不獨立顯示在頁面上方，無法加入 FTB 原生工具列，導致視覺與操作體驗顯得不一致。作者指出，FTB 其實還有許多好用的工具可直接啟用，只是受限於 CS 的包裝與原始碼缺漏，無法完整發揮；最後達成需求但不夠優雅，對整體一致性與可用性的提升有限，感到有些可惜。
資訊整理
知識架構圖
- 前置知識：
- 了解 ASP.NET Web Forms 基本結構與控制項
- 熟悉 WYSIWYG 編輯器（FreeTextBox, FTB）的基本設定方式
- 知道 Community Server（CS）的架構與可擴充點
- 具備前端工具列/插件整合的基本概念
- 核心概念：
- Community Server 的 Editor Wrapper：CS 並非直接嵌入 FTB，而是包在自家的封裝層中
- FreeTextBox（FTB）可擴充性：FTB 原生支援許多工具列功能
- 原始碼缺口：CS 提供的原始碼缺少 Editor Wrapper 部分
- 整合限制：由於封裝與缺碼，無法將自訂工具列直接合併進 FTB 原生工具列
- UI 折衷方案：自訂的額外工具列只能獨立顯示在畫面上方，造成「格格不入」
- 技術依賴：
- CS 的部落格編輯器功能依賴 FTB
- FTB 的自訂與工具列整合又依賴直接操作 FTB 物件或其設定 API
- CS 封裝層攔截或抽象了 FTB，使直接操作 FTB 工具列受限
- 缺少封裝層原始碼導致無法在封裝層內部進行擴充或調整掛載點
- 應用場景：
- 在 Community Server 上擴充部落格 editor 功能（貼圖、表情）
- 想開啟或整合 FTB 既有的工具列與功能
- 在缺乏封裝層原始碼的情況下，採用 UI/功能折衷方案的客製化
學習路徑建議
- 入門者路徑：
- 認識 CS 的編輯器使用流程（從頁面到編輯器呼叫）
- 熟悉 FreeTextBox 的基本設定與常見 toolbar 功能
- 嘗試在不修改封裝層的情況下，加上最小可行的外掛功能（例如貼圖、表情）以驗證流程
- 進階者路徑：
- 研究 CS Editor Wrapper 的載入點與生命週期（就算缺碼，也可透過反射、瀏覽器 DevTools 觀察 DOM 結構與事件）
- 評估如何以獨立工具列方式與 FTB 互動（呼叫 FTB 的插入指令、選取範圍 API）
- 探索以設定覆寫、皮膚/主題、或客製控件注入來減少「格格不入」的 UI 感
- 實戰路徑：
- 建立一組自訂貼圖/表情功能：上傳/選擇介面 + 對 FTB 的插入行為
- 將自訂工具列的樣式與位置調整與 FTB 視覺一致（CSS/樣式覆寫）
- 列出 FTB 尚可開啟的工具列功能與可行的代替方案，逐項測試與整合
關鍵要點清單
- CS 使用 FTB 作為底層編輯器：核心依賴關係是 CS → FTB（優先級: 高）
- 存在 Editor Wrapper 封裝層：CS 不是直接嵌入 FTB（優先級: 高）
- 原始碼缺失問題：CS 提供的原始碼缺少 Editor Wrapper 部分（優先級: 高）
- 無法直接擴充 FTB 工具列：因封裝+缺碼導致工具列整合受阻（優先級: 高）
- 外掛工具列折衷：自訂工具列需要獨立顯示在畫面上方（優先級: 中）
- FTB 原生功能豐富：許多可用工具列功能本可直接開啟（優先級: 中）
- UI 一致性挑戰：外加工具列與 FTB 原生列難以無縫整合（優先級: 中）
- 插入內容能力需求：目標功能為貼圖與表情插入（優先級: 高）
- 可觀察與反射策略：缺碼情境下借助 DOM 觀察或反射理解行為（優先級: 低）
- 設定與樣式覆寫：透過 CSS/樣式讓外加工具列接近原生外觀（優先級: 中）
- 指令層整合：以 FTB API/指令方式觸發插入動作（優先級: 中）
- 最小可行整合：先讓功能可用，再逐步改善體驗（優先級: 高）
- 技術風險管理：缺少封裝層碼即代表維護成本高與局限大（優先級: 中）
- 項目可行性評估：若需深度整合，可能需替換封裝或尋求替代路徑（優先級: 中）
- 可見度與回饋：使用者對「格格不入」的容忍度影響取捨（優先級: 低）
