[BlogEngine.NET] Widgets

以下案例均根據原文內容所涉及的真實場景與技術脈絡重組，聚焦「BlogEngine.NET 1.4 Widget」帶來的遷移、開發、部署與可視化管理能力。每一案皆包含問題、根因、可落地的解決方案（附關鍵程式碼/設定）、可觀察的實際效益與可執行的練習與評估標準。共 16 案。

Problem Statement（問題陳述）

業務場景：原先想在 BlogEngine.NET 實作 Extension，並需要為擴充功能保存自訂設定（如 API Key、顯示數量、佈局選項）。在翻找資料時發現 Extension 設定保存機制說明不足，影響開發進度。最終在查找過程中發現 BlogEngine.NET 1.4 引入的 Widgets 機制，支援可視化設定與拖拉佈局，於是考慮將需求改以 Widget 實作。技術挑戰：缺少 Extension 設定的官方最佳實務與樣例；需求包含設定表單、視覺化呈現與可重複使用。影響範圍：延誤開發排程、重複造輪子（自實作設定儲存/管理 UI）、難以部署與給非技術站長管理。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

Extension 設定保存文件稀缺：缺少清晰 API 與範例導致估時不確定。
設定 UI 需求被忽略：Extension 原生並非主打可視化設定。
部署與版本差異：不同版本對 Extension 的行為差異難以快速掌握。

深層原因：

架構層面：Extension 更偏向事件攔截與全站掛載，不是以視覺組件為中心。
技術層面：缺少現成設定編輯器與 UI/存儲協作範式。
流程層面：需求調研到位前即開發，導致選型來回。

Solution Design（解決方案設計）

解決策略：將原本打算用 Extension 實作的功能改以 Widget 模式落地。Widget 天生帶有「視覺化 + 設定編輯器 + 拖拉佈局 + 獨立部署」特性，符合需求且開發門檻低（User Control + 指定目錄 + 指定基底類別）。

實施步驟：

決策切換：由 Extension 轉 Widget
- 實作細節：梳理功能點，拆分為展示區（View.ascx）與設定編輯器（Edit.ascx）
- 所需資源：BlogEngine.NET 1.4、開發工具（Visual Studio）
- 預估時間：0.5 人日
建立 Widget 骨架
- 實作細節：建立 ~/Widgets/{YourWidget}/ 下的 *.ascx 與後置程式，繼承 WidgetBase
- 所需資源：BE Core 參照
- 預估時間：0.5 人日
移植/撰寫設定存取
- 實作細節：使用 Widget 設定 API 儲存字典，映射至欄位
- 所需資源：BlogEngine 核心命名空間
- 預估時間：0.5 人日

關鍵程式碼/設定：

// 概念性範例：WidgetBase 與設定存取（版本 1.4 之常見樣式，命名可能因版本微調） 
using BlogEngine.Core.Web.Controls;
using System.Collections.Specialized;

public class MyWidget : WidgetBase
{
    public override bool IsEditable => true;
    public override string Name => "MyWidget";
    public override string Description => "Sample widget using built-in settings";

    public override void LoadWidget()
    {
        // 載入設定並渲染使用者控制項
        var settings = GetSettings();
        var title = settings["Title"] ?? "Default Title";
        // 將設定傳入 View（可用 FindControl 或載入子控件）
    }

    NameValueCollection GetSettings()
    {
        // 取得與此 Widget 實例綁定的設定字典
        return base.Settings;
    }

    public override void SaveWidget()
    {
        // 由編輯器 Edit.ascx 呼叫，或框架在編輯完成時呼叫
        // 範例：Settings["Title"] = 收集於 TextBox 的值
    }
}

實際案例：作者原先要找 Extension 設定做法，轉而採用 Widget 架構，迅速完成設定編輯與展示。實作環境：BlogEngine.NET 1.4、ASP.NET WebForms、.NET Framework（當年環境）實測數據：改善前：需自行找出 Extension 設定儲存與 UI 範式改善後：改用 Widget 原生設定編輯 + 存儲機制改善幅度：需求落地時間縮至「數小時級」（文中提及試 1-2 小時即動工）

Learning Points（學習要點）核心知識點：

Extension 與 Widget 的定位差異
WidgetBase 的生命週期與設定持久化
用 User Control 快速拼裝 UI

技能要求：

必備技能：ASP.NET WebForms User Control、C#
進階技能：BlogEngine 核心類別與設定 API

延伸思考：

若功能需全站事件攔截，仍以 Extension 為宜
大量設定項時，需考量編輯器可用性/驗證

Practice Exercise（練習題）

基礎：把一個 TextBox 設定值持久化到 Widget 設定
進階：支援多欄位設定並加上驗證
專案：將一個現有 Extension（帶設定）重構成 Widget

Assessment Criteria（評估標準）

功能完整性（40%）：設定可保存、載入、呈現
程式碼品質（30%）：分層清楚、命名一致
效能優化（20%）：設定存取與渲染無冗餘
創新性（10%）：設定 UI 體驗佳

Problem Statement（問題陳述）

業務場景：部落格側欄需要展示 Flickr 相片牆，站長希望以最小代碼與最少耦合快速上線，並能透過簡單設定（Flickr UserId、顯示數量）調整顯示內容。技術挑戰：整合第三方 API（FlickrNet）、處理資料抓取、快取與簡潔呈現，同時需可視化調整設定。影響範圍：內容呈現力、站點美觀度與互動性，亦影響 Sidebar 元件可重複使用性。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

缺少現成相片 Widget：需自製。
資料抓取與展示耦合：需要清楚分離 View/Editor。
部署便捷性要求：希望丟入 ~/Widgets/ 即生效。

深層原因：

架構層面：需要可插拔、可配置的小工具架構。
技術層面：第三方 API 整合 + WebForms UI。
流程層面：希望快速迭代，優先落地可用版本。

Solution Design（解決方案設計）

解決策略：用兩個 User Control（View/Edit）+ WidgetBase 實作 Flickr 小工具。View 負責呼叫 FlickrNet 取回圖片並繫結；Edit 寫入設定字典（UserId、Count）。部署至 ~/Widgets/ 後由站長拖拉到頁面。

實施步驟：

新增 View.ascx 與 Code-behind
- 實作細節：呼叫 FlickrNet API 依 UserId/Count 取得相片
- 所需資源：FlickrNet 套件、Flickr API Key
- 預估時間：0.5 人日
新增 Edit.ascx 設定介面
- 實作細節：TextBox 綁定 UserId/Count，保存到 Settings
- 所需資源：WebForms 控件
- 預估時間：0.5 人日
小工具註冊與部署
- 實作細節：繼承 WidgetBase，覆寫 LoadWidget/SaveWidget
- 所需資源：BE 核心類別
- 預估時間：0.5 人日

關鍵程式碼/設定：

// View.ascx.cs - 以 FlickrNet 取圖並繫結 Repeater（示意）
using FlickrNet;
using System.Collections.Generic;

public partial class FlickrView : System.Web.UI.UserControl
{
    public string UserId { get; set; }
    public int Count { get; set; } = 8;

    protected void Page_Load(object sender, EventArgs e)
    {
        if (!IsPostBack) BindPhotos();
    }

    void BindPhotos()
    {
        var flickr = new Flickr("YOUR_API_KEY", "YOUR_API_SECRET");
        var photos = flickr.PeopleGetPublicPhotos(UserId, 1, Count);
        rpt.DataSource = photos;
        rpt.DataBind();
    }
}

// Widget 控制主持久化（示意）
using BlogEngine.Core.Web.Controls;
using System.Collections.Specialized;

public class FlickrWidget : WidgetBase
{
    public override bool IsEditable => true;
    public override string Name => "Flickr Photos";

    public override void LoadWidget()
    {
        var settings = Settings;
        var userId = settings["UserId"] ?? "";
        var count = int.TryParse(settings["Count"], out var c) ? c : 8;

        var view = (FlickrView)Page.LoadControl("~/Widgets/Flickr/View.ascx");
        view.UserId = userId;
        view.Count = count;
        this.Controls.Add(view);
    }

    public override void SaveWidget()
    {
        // 由 Edit.ascx 收集資料並寫入 Settings
        // Settings["UserId"] = ...
        // Settings["Count"] = ...
    }
}

實際案例：作者參考強者的 FlickrNet 小工具範例，幾行代碼便運作，並能在 Widget 框架下可視化配置。實作環境：BlogEngine.NET 1.4、FlickrNet、.NET Framework 實測數據：改善前：需在版面硬寫 HTML/JS 或自製模組改善後：Widget 可拖放、可編輯，部署即用改善幅度：開發落地時間縮至「幾行代碼/數小時」

Learning Points（學習要點）

FlickrNet 整合套路（API Key、拉資料、繫結）
Widget View/Edit 分離
設定持久化與注入

技能要求：

必備：WebForms、C#、基本第三方 API 使用
進階：快取、錯誤處理、CDN 圖片載入最佳化

延伸思考：

可加入快取避免每次 API 呼叫
加入 Lazy-load 與圖片壓縮提升效能

Practice Exercise：

基礎：實作 UserId/Count 設定與照片繫結
進階：新增相片點擊放大（Lightbox）
專案：做一個可多來源（Flickr/Instagram）的相片 Widget

Assessment Criteria：

功能完整性（40%）：可配置、可呈現
程式碼品質（30%）：解耦、命名、例外處理
效能優化（20%）：快取、圖片載入策略
創新性（10%）：互動體驗

Problem Statement（問題陳述）

業務場景：站長在前台希望點擊 [Edit] 即可修改 Widget 的參數（如 Flickr UserId、顯示數量），不需修改代碼或登入後台深層設定。技術挑戰：在 BlogEngine 的 Widget 流程中，如何將 Edit 控制項與 View/設定持久化順利串接。影響範圍：非技術使用者自助能力、維運負擔、發佈效率。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

設定 UI 缺少標準化樣板。
設定結果需回寫到 Widget 的設定字典。
要配合框架的保存觸發點。

深層原因：

架構層面：Widget 編輯/顯示兩階段。
技術層面：控件間資料傳遞與狀態管理。
流程層面：可視化編輯流程要直覺。

Solution Design（解決方案設計）

解決策略：建立 Edit.ascx，於 Page_Load 值繫結，保存事件回寫 Settings，WidgetBase.SaveWidget 接合框架保存流程。

實施步驟：

建 Edit.ascx 介面
- 實作細節：TextBox for UserId, Count；驗證輸入
- 所需資源：WebForms Controls
- 預估時間：0.25 人日
寫入/讀取 Settings
- 實作細節：Edit.Load -> 導入 Settings；保存 -> 寫回 Settings
- 所需資源：WidgetBase.Settings
- 預估時間：0.25 人日

關鍵程式碼/設定：

// Edit.ascx.cs（示意）
public partial class FlickrEdit : System.Web.UI.UserControl
{
    public NameValueCollection Settings { get; set; }

    protected void Page_Load(object sender, EventArgs e)
    {
        if (!IsPostBack && Settings != null)
        {
            txtUserId.Text = Settings["UserId"] ?? "";
            txtCount.Text = Settings["Count"] ?? "8";
        }
    }

    public void Save()
    {
        Settings["UserId"] = txtUserId.Text.Trim();
        Settings["Count"] = txtCount.Text.Trim();
    }
}

實際案例：作者提到第二個 User Control 專職編輯設定，幾個 TextBox 即搞定。實作環境：BlogEngine.NET 1.4、ASP.NET WebForms 實測數據：改善前：需修改程式碼或手動改設定檔改善後：前台可視化 [Edit] 直接保存改善幅度：非工程師也可操作，維運工時明顯降低

Learning Points：

Settings 字典在 Edit/View 之間傳遞
驗證與預設值策略
編輯與保存觸發

Practice Exercise：

基礎：兩個欄位讀寫 Settings
進階：加入 Required/Range 驗證
專案：多分頁設定（Tab）與群組驗證

Assessment Criteria：

功能完整性：可讀可寫、錯誤提示
代碼品質：清晰、解耦
效能：輕量無多餘回發
創新性：良好 UX

Problem Statement（問題陳述）

業務場景：希望用最少步驟讓新 Widget 在站點可用。理想狀態是將檔案放到 ~/Widgets/ 專屬資料夾即可出現於可拖放清單中。技術挑戰：需符合 BlogEngine 的 Widget 規範（目錄結構、基底類別、命名）。影響範圍：部署效率、跨環境移轉難易度、失敗率。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

目錄與檔案命名不一致導致框架無法掃描。
基底類別非 WidgetBase。
遺漏 Edit/View 控制項導致編輯失敗。

深層原因：

架構層面：Widget 掃描與載入有固定契約。
技術層面：WebForms 控件路徑與動態載入。
流程層面：缺少標準發佈包與檢核清單。

Solution Design（解決方案設計）

解決策略：制定最小規範：每個 Widget 一個資料夾，包含 View.ascx、Edit.ascx、Widget 繼承類別；遵循命名慣例；提供簡單自檢清單。

實施步驟：

建立標準資料夾
- 實作細節：~/Widgets/Flickr/, ~/Widgets/Ads/
- 所需資源：檔案系統
- 預估時間：0.1 人日
檢核基底與命名
- 實作細節：Widget class 繼承 WidgetBase；對應載入 View 與 Edit
- 所需資源：BlogEngine 命名空間
- 預估時間：0.1 人日

關鍵程式碼/設定：

// 檢核清單（註解示意）
// - 目錄：~/Widgets/{Name}/
// - 顯示控件：View.ascx (+ .cs)
// - 編輯控件：Edit.ascx (+ .cs)（如需編輯）
// - 入口類別：{Name}Widget.cs : WidgetBase
// - 動態載入：Page.LoadControl("~/Widgets/{Name}/View.ascx")

實際案例：作者表示放到 ~/Widgets/ 就「簡單到想打人」。實作環境：BlogEngine.NET 1.4 實測數據：改善前：手工改版面、散落檔案改善後：單一資料夾化、丟進去即生效改善幅度：部署步驟數下降為「複製即可」

Learning Points：

Widget 掃描契約與載入流程
檔案結構契約化帶來的部署便利

Practice Exercise：

基礎：建立一個 HelloWorld Widget 丟進 ~/Widgets/ 可見
進階：包含 Edit 控制項與保存
專案：建立部署腳本自動打包拷貝

Assessment Criteria：

功能完整性：能被掃描、顯示、編輯
代碼品質：結構清晰
效能：載入延遲可接受
創新性：自動化打包工具

Case #5: 啟用 1.4 的拖拉與 [Edit] 編輯流程

Problem Statement（問題陳述）

業務場景：站長希望像 Web Parts 一樣，直接在頁面上把 Widget 拖到喜歡的位置，並按 [Edit] 切換到編輯介面調整設定。技術挑戰：理解 BlogEngine.NET 1.4 的前台 Widget 管理流程、權限與保存。影響範圍：內容管理效率與 UX，降低開發介入頻率。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

舊版不支援拖拉/可視化編輯。
未啟用或不熟悉 1.4 功能入口。
主題未提供 Widget Zone。

深層原因：

架構層面：1.4 新增 Widget 管理器。
技術層面：前端拖放與伺服器狀態保存協作。
流程層面：站長前台即時調整內容。

Solution Design（解決方案設計）

解決策略：在具備 Widget Zone 的主題中，切換管理模式，使用前台工具列進行 Widget 新增、拖放、編輯、儲存。確保權限控管與 Zone 命名清楚。

實施步驟：

確認主題具 Widget Zone
- 實作細節：Master/頁面含 WidgetZone 控件
- 所需資源：主題檔案
- 預估時間：0.25 人日
前台操作與保存
- 實作細節：登入管理員，在頁面進入布局模式，拖拉並 [Edit] 保存
- 所需資源：管理員帳號
- 預估時間：0.25 人日

關鍵程式碼/設定：

<!-- 主題中放置 Widget Zone（示意，實際屬性依版本） -->
<blog:WidgetZone runat="server" ID="RightSidebarZone" />

實際案例：作者描述 1.4 後可拖拉新增、按 [EDIT] 切換到編輯控制項、按 OK 存檔。實作環境：BlogEngine.NET 1.4 實測數據：改善前：需改版面檔案、重新部署改善後：前台拖拉即時生效改善幅度：內容上線時間大幅縮短（由開發/部署改為站長即時操作）

Learning Points：

Web Parts 概念在 BE 的對應
前台管理與權限需求

Practice Exercise：

基礎：在 RightSidebarZone 新增兩個 Widget 並排序
進階：調整設定、觀察不同實例的設定隔離
專案：規劃多 Zone（Header/Footer/Sidebar）佈局

Assessment Criteria：

功能完整性：可拖拉、可編輯、可保存
代碼品質：Zone 命名與結構合理
效能：拖拉操作流暢
創新性：佈局規劃

Case #6: 快速升級 BlogEngine.NET 到 1.4 以啟用 Widgets

Problem Statement（問題陳述）

業務場景：部落格剛搬家即發現 BlogEngine.NET 1.4 發佈，帶來 Widget 能力。希望立即升級以享受新功能。技術挑戰：升級風險控制、配置合併、相容性檢查（尤其主題）。影響範圍：站點穩定性、功能可用性、升級時間窗口。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

舊版缺少 Widget 新能力。
升級後主題可能不支援 Widgets。
需要快速驗證升級可用性。

深層原因：

架構層面：版本變更帶來檔案/設定差異。
技術層面：Web.config 與組件更新。
流程層面：先備份、後升級、再驗證。

Solution Design（解決方案設計）

解決策略：遵循「備份-清單-升級-驗證」四步法。優先確保核心運作與 Widget 功能，主題不支援者先以預設主題驗證功能，後續再遷移主題。

實施步驟：

備份與對比
- 實作細節：完整備份檔案/DB；Diff 新舊檔案清單
- 所需資源：版本包、Diff 工具
- 預估時間：0.5 人日
升級與預設主題驗證
- 實作細節：覆蓋核心檔案，先用預設主題測試 Widgets
- 所需資源：官方 1.4 套件
- 預估時間：0.5 人日
主題相容性處理
- 實作細節：若自訂主題不支援 Widgets，後續 Case #7 處理
- 預估時間：視主題複雜度而定

關鍵程式碼/設定：

升級檢核清單（節選）
- 備份 App_Data（文章/留言等）
- 對比 /bin 與核心程式庫版本
- 臨時切換到預設主題，驗證 WidgetZone 正常
- 還原/合併 Web.config 差異

實際案例：作者花 1-2 小時測試就動工，最終成功搬到 1.4。實作環境：BlogEngine.NET 1.4 實測數據：改善前：無 Widget 支援改善後：Widgets 啟用，前台可視化管理改善幅度：功能面從 0 到 1；升級投入：數小時

Learning Points：

升級風險控制方法論
先驗證核心功能再處理主題相容

Practice Exercise：

基礎：在測試環境完成 1.4 升級演練
進階：撰寫升級自動化 Script（備份/覆蓋/驗證）
專案：制定升級 SOP 與回滾計畫

Assessment Criteria：

功能完整性：升級後核心功能與 Widgets 正常
程式碼品質：設定合併無遺漏
效能：升級後無顯著退化
創新性：自動化與文件化程度

Problem Statement（問題陳述）

業務場景：現有自訂主題（樣板）不支援 Widget。升級到 1.4 後想使用 Widgets，但主題缺少 WidgetZone 導致功能無法呈現。技術挑戰：在不破壞現有風格下，將 WidgetZone 安全嵌入主題與版位。影響範圍：佈局可用性、視覺一致性、升級價值實現。複雜度評級：中-高（視主題複雜度）

Root Cause Analysis（根因分析）

直接原因：

主題未置入 WidgetZone 控件。
佈局未預留作為 Widget 容器的區塊。
樣式（CSS）未對應 Widget 結構。

深層原因：

架構層面：主題與 Widget 管理器需要契合點。
技術層面：Master Page、CSS、可拖放占位對應。
流程層面：樣板移植策略落後於版本升級。

Solution Design（解決方案設計）

解決策略：為主題新增 WidgetZone，對齊預設主題的 DOM 結構與 CSS Class；以小步驟驗證（先右側 Sidebar，再逐步擴展）。

實施步驟：

新增 WidgetZone 區塊
- 實作細節：在 Master 的 Sidebar 區插入
- 所需資源：主題原始碼
- 預估時間：0.5-1 人日
調整 CSS 與樣式
- 實作細節：套用與預設主題一致的 Widget 容器樣式（如 widget-box）
- 所需資源：CSS
- 預估時間：0.5 人日

關鍵程式碼/設定：

<!-- 自訂主題 Master 頁，加入右側 Widget 區 -->
<div id="sidebar">
  <blog:WidgetZone runat="server" ID="RightSidebarZone" />
</div>

/* CSS（示意） */
.widget-box {
  margin-bottom: 12px;
}

實際案例：作者指出現有樣板不支援 Widget，需自行忙一波做相容。實作環境：BlogEngine.NET 1.4、自訂主題實測數據：改善前：升級後無法用 Widgets 改善後：右側 Box 等可用 Widgets 動態管理改善幅度：從無到有；前台可視化管理能力解鎖

Learning Points：

主題與 Widget 的整合要點
小步驗證策略降低風險

Practice Exercise：

基礎：在主題加入單一 WidgetZone
進階：讓多 Column 主題每欄都支援 WidgetZone
專案：把舊主題完整遷移至 Widget 友善結構

Assessment Criteria：

功能完整性：Widget 可見、可拖拉
代碼品質：主題 DOM 與 CSS 清晰
效能：版面渲染穩定
創新性：主題擴充彈性

Problem Statement（問題陳述）

業務場景：側欄原有 Google 廣告（AdSense）區塊是硬寫在主題。站長希望透過 Widget 管理它的位置與顯示，避免每次修改都改主題檔。技術挑戰：把廣告腳本安全封裝，提供標題/版位/大小等設定。影響範圍：營收位管理、佈局靈活性、部署風險。複雜度評級：低-中

Root Cause Analysis（根因分析）

直接原因：

廣告碼硬耦合在主題。
佈局調整需要動到程式碼。
無法前台調整與測試。

深層原因：

架構層面：主題承載太多動態內容責任。
技術層面：腳本安全與輸入驗證。
流程層面：營收位需要頻繁 A/B 調整。

Solution Design（解決方案設計）

解決策略：封裝 AdSense 代碼為 Widget，Edit 提供 ClientId、Slot、Size、ContainerClass 等設定；以 Literal 安全輸出，並提供可切換外框樣式。

實施步驟：

View 顯示廣告
- 實作細節：組裝廣告 script/html，避免內嵌危險字串
- 所需資源：AdSense 代碼
- 預估時間：0.5 人日
Edit 設定欄位
- 實作細節：TextBox/DropDown、基本驗證
- 所需資源：WebForms 控件
- 預估時間：0.5 人日

關鍵程式碼/設定：

// AdsView.ascx.cs（示意）
protected void Page_Load(object sender, EventArgs e)
{
    if (!IsPostBack)
    {
        var client = Settings["ClientId"];
        var slot = Settings["SlotId"];
        litAd.Text = $@"<ins class='adsbygoogle' data-ad-client='{client}' data-ad-slot='{slot}'></ins>
<script>(adsbygoogle=window.adsbygoogle||[]).push({{}});</script>";
    }
}

實際案例：作者點名右側的 Google 廣告 Box，遷移到 Widget 後可拖放與編輯。實作環境：BlogEngine.NET 1.4、AdSense 實測數據：改善前：改位子/樣式需改主題改善後：前台拖拉調整位置，設定可視化改善幅度：維運效率顯著提升

Learning Points：

安全輸出第三方腳本
佈局與內容責任分離

Practice Exercise：

基礎：把廣告碼做成 Widget
進階：多尺寸選項與外框主題切換
專案：多廣告位管理（Header/Sidebar/Footer）

Assessment Criteria：

功能完整性：廣告顯示與設定可用
代碼品質：輸出安全、結構清楚
效能：不影響頁面載入
創新性：多位自動化管理

Problem Statement（問題陳述）

業務場景：側欄有「安德魯是誰？」的簡介區塊，過去寫死在主題。希望讓站長可直接在前台編輯簡介內容。技術挑戰：提供簡便的富文本或 Markdown 輸入，並確保安全輸出。影響範圍：品牌介紹、轉化、維運效率。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

靜態內容每次改都需改檔。
無法前台就地編輯。
無版本回溯。

深層原因：

架構層面：內容與主題耦合。
技術層面：輸入安全、格式化顯示。
流程層面：內容更新頻繁。

Solution Design（解決方案設計）

解決策略：建立「About」Widget，Edit 支援多行輸入與基本樣式，View 安全輸出。可選擇是否啟用簡易 Markdown。

實施步驟：

View 顯示
- 實作細節：Literal 控制項輸出，白名單樣式
- 所需資源：HTML Sanitizer（選）
- 預估時間：0.5 人日
Edit 編輯
- 實作細節：TextBox TextMode=MultiLine
- 所需資源：驗證與字數限制
- 預估時間：0.5 人日

關鍵程式碼/設定：

// AboutView.ascx.cs（示意）
protected void Page_Load(object sender, EventArgs e)
{
    if (!IsPostBack)
    {
        var content = Settings["AboutText"] ?? "尚未填寫";
        litAbout.Text = HttpUtility.HtmlEncode(content).Replace("\n", "<br/>");
    }
}

實際案例：「安德魯是誰？」屬右側 Box 範疇，Widget 化後可視化管理。實作環境：BlogEngine.NET 1.4 實測數據：改善前：需改主題檔改善後：前台編輯保存即可改善幅度：內容更新工時由「開發/部署」降為「即時」

Learning Points：

Rich Text vs 安全輸出
小內容區塊的維運最佳化

Practice Exercise：

基礎：多行文字保存與顯示
進階：允許簡單連結/粗體（白名單）
專案：多語系 About Widget

Assessment Criteria：

功能完整性：可編輯、可保存、可顯示
代碼品質：安全處理
效能：輕量
創新性：格式化支援

Problem Statement（問題陳述）

業務場景：側欄需展示最新回應，提升互動可見度。希望以 Widget 呈現，方便排序與組合。技術挑戰：拉取資料與快取、避免頻繁查詢影響效能。影響範圍：互動曝光、頁面載入效能。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

每次載入都查資料庫可能影響性能。
需要可配置顯示數、是否顯示片段。
與其他 Widget 排序互動。

深層原因：

架構層面：Widget 即插即用需最佳化。
技術層面：資料來源與快取策略。
流程層面：需要無痛熱部署。

Solution Design（解決方案設計）

解決策略：將最新回應以 Widget 提供，Edit 設定顯示數與顯示長度；採 MemoryCache 短期快取，降低讀取壓力。

實施步驟：

View 資料繫結
- 實作細節：呼叫 BlogEngine 核心 API 取最新回應
- 所需資源：BE Core
- 預估時間：0.5 人日
快取策略
- 實作細節：每 60 秒更新一次
- 所需資源：MemoryCache
- 預估時間：0.25 人日

關鍵程式碼/設定：

// 以快取包覆取回最新回應（示意）
var cacheKey = "latest-comments";
var items = MemoryCache.Default.Get(cacheKey) as List<Comment>;
if (items == null)
{
    items = LoadLatestCommentsFromCore(); // 呼叫 BlogEngine Core
    MemoryCache.Default.Add(cacheKey, items, DateTimeOffset.UtcNow.AddSeconds(60));
}
rpt.DataSource = items.Take(count);
rpt.DataBind();

實際案例：作者列舉右側「最新回應」為 Box 類型，Widget 化是自然做法。實作環境：BlogEngine.NET 1.4 實測數據：改善前：硬嵌在主題或無快取改善後：Widget 可調整並快取改善幅度：資料庫壓力降低，排序/佈局自由度提升

Learning Points：

Widget 與快取協作
可配置顯示與效能平衡

Practice Exercise：

基礎：顯示最近 N 筆
進階：加入快取與內容截斷
專案：可切換不同排序（最新/最熱）

Assessment Criteria：

功能完整性：資料正確可配置
代碼品質：快取與錯誤處理
效能：快取命中率
創新性：多模式展示

Problem Statement（問題陳述）

業務場景：同一 Widget 放在兩個區域（例如左右側欄）時，希望各自設定不同參數（如顯示數、標題）。技術挑戰：區分與持久化不同實例的設定而不互相覆蓋。影響範圍：內容彈性、版面組合自由度。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

單一設定字典易被覆蓋。
編輯器需對應實例 ID。
保存流程需使每個實例獨立。

深層原因：

架構層面：Widget 管理器以實例為單位。
技術層面：實例 ID 與設定存取 API 關聯。
流程層面：前台編輯每個實例分離保存。

Solution Design（解決方案設計）

解決策略：使用 WidgetBase 提供的實例關聯設定存取（Settings 與當前 Widget 實例綁定），避免共用靜態設定。

實施步驟：

在 Load/Save 時以當前實例 Settings 操作
- 實作細節：不要用全域單例保存設定
- 所需資源：WidgetBase API
- 預估時間：0.25 人日
編輯器以當前 Widget 實例上下文為準
- 實作細節：透過框架注入或傳遞 Settings
- 0.25 人日

關鍵程式碼/設定：

// 在 WidgetBase 中，Settings 已綁定實例
public override void LoadWidget()
{
    var title = Settings["Title"]; // 每個實例取得各自值
}
public override void SaveWidget()
{
    Settings["Title"] = CurrentEditor.Title; // 只影響當前實例
}

實際案例：文中提到可在頁面上拉多個 Widget，Edit 後保存；自然需要實例級隔離。實作環境：BlogEngine.NET 1.4 實測數據：改善前：設定共享導致彼此覆蓋改善後：每個實例各自保存改善幅度：版面組合能力提升（從 1 設定到 N 設定）

Learning Points：

實例 ID 與設定字典的對應
避免靜態/全域狀態

Practice Exercise：

基礎：同一 Widget 放兩處，設定不同標題
進階：加入多欄位差異化設定
專案：多實例統計匯出與備份

Assessment Criteria：

功能完整性：不同實例設定互不干擾
代碼品質：無共享狀態陷阱
效能：設定存取穩定
創新性：實例管理 UI

Problem Statement（問題陳述）

業務場景：站長在前台需要從顯示模式切換到編輯模式（[Edit]）並在完成後回到顯示模式，流程需直覺與穩定。技術挑戰：在 WebForms PostBack 與 WidgetBase Save 流程間妥善傳遞狀態與錯誤。影響範圍：使用體驗、錯誤率、保存成功率。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

狀態切換需要維持目前實例上下文。
保存後需要回到顯示模式。
錯誤需友善提示而非白屏。

深層原因：

架構層面：兩段式 UI。
技術層面：PostBack 與控件動態載入。
流程層面：簡潔且可回滾。

Solution Design（解決方案設計）

解決策略：以 WidgetBase 控制流為中心，顯示模式載入 View；按下 [Edit] 切換載入 Edit；保存成功後寫 Settings 並重載 View；失敗則留在 Edit 顯示錯誤。

實施步驟：

切換編輯狀態
- 實作細節：依框架傳入旗標或按鈕 Command 觸發
- 預估時間：0.25 人日
錯誤處理
- 實作細節：Try/Catch，ValidationSummary
- 預估時間：0.25 人日

關鍵程式碼/設定：

// WidgetBase 管理載入（示意）
if (IsInEditMode)
{
    var editor = (FlickrEdit)LoadControl("~/Widgets/Flickr/Edit.ascx");
    editor.Settings = Settings;
    this.Controls.Add(editor);
}
else
{
    var view = (FlickrView)LoadControl("~/Widgets/Flickr/View.ascx");
    // 傳入設定
    this.Controls.Add(view);
}

實際案例：作者描述按 [EDIT] 即切到編輯用的 User Control，OK 就存檔。實作環境：BlogEngine.NET 1.4 實測數據：改善前：需進後台或改檔改善後：就地編輯保存改善幅度：操作步驟顯著簡化

Learning Points：

兩階段 UI 模式切換
錯誤顯示與回退策略

Practice Exercise：

基礎：完成 Edit -> Save -> View 流程
進階：保存失敗留在 Edit 並提示
專案：編輯歷史與取消變更

Assessment Criteria：

功能完整性：流程通順
代碼品質：狀態管理清晰
效能：最少 PostBack
創新性：友善 UX

Problem Statement（問題陳述）

業務場景：右側有多個 Box（Google 廣告、安德魯是誰、最新回應），原先硬寫在主題。希望全面 Widget 化，讓站長能自由組合、排序、開關。技術挑戰：批次拆分、建立多個 Widget、確保樣式一致性。影響範圍：運營效率、內容敏捷性、長期維護成本。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

多個 Box 與主題耦合。
每個修改都需改主題檔。
排序/開關需手工。

深層原因：

架構層面：缺少組件化思路。
技術層面：UI 元件抽象不足。
流程層面：內容運營與開發綁死。

Solution Design（解決方案設計）

解決策略：將每個 Box 抽象成獨立 Widget（Case 8/9/10），推動側欄 100% Widget 化；主題只保留 WidgetZone 容器。

實施步驟：

Box 清單與拆分
- 實作細節：列出現有 Box，逐一建對應 Widget
- 預估時間：1-2 人日
樣式統一
- 實作細節：統一 widget-box 樣式
- 預估時間：0.5 人日

關鍵程式碼/設定：

/* 統一外框樣式 */
.widget-box { border: 1px solid #ddd; padding: 8px; margin-bottom: 12px; }
.widget-title { font-weight: bold; margin-bottom: 6px; }

實際案例：作者列舉的三種 Box 全是 Widget 候選，1.4 後正式變成元件。實作環境：BlogEngine.NET 1.4 實測數據：改善前：改動需發版改善後：站長拖拉、排序、編輯即可改善幅度：操作中心從「開發」轉為「運營」

Learning Points：

組件化與主題職責分離
批次改造策略

Practice Exercise：

基礎：將一個 Box 下線主題、上線 Widget
進階：三個 Box 全部 Widget 化並統一樣式
專案：建立 Widget 目錄與命名規範

Assessment Criteria：

功能完整性：Box 功能不退步
代碼品質：風格一致
效能：載入正常
創新性：運營能力提升

Case #14: 小步快跑驗證（1-2 小時內完成 PoC）

Problem Statement（問題陳述）

業務場景：為降低升級與改造風險，團隊需要在短時間內做出可用 Demo（PoC），驗證 Widget 機制可行並評估工作量。技術挑戰：在最短時間內把一個 Widget 跑起來，覆蓋「顯示 + 編輯 + 保存」三件事。影響範圍：決策信心、排程、風險控制。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

缺乏對 1.4 的實際手感。
需要快速佐證可行性。
資源有限。

深層原因：

架構層面：新功能落地需要最小閉環。
技術層面：避免過度設計。
流程層面：先證明，再擴展。

Solution Design（解決方案設計）

解決策略：按最小閉環原則，實作一個「標題 + 內容文本」的簡單 Widget（View + Edit + Save）。成功後再擴展到 Flickr/Ads 等。

實施步驟：

建最小 Widget
- 實作細節：一個標題、一段文字，支援編輯與保存
- 預估時間：1 小時
驗證拖拉與部署
- 實作細節：丟入 ~/Widgets/，拖拉與保存
- 預估時間：0.5 小時

關鍵程式碼/設定：

// MinimalWidget.cs : WidgetBase（示意）
public override void LoadWidget()
{
    var title = Settings["Title"] ?? "Demo";
    var content = Settings["Content"] ?? "Hello Widget";
    litTitle.Text = title;
    litContent.Text = content;
}

實際案例：作者花 1-2 小時試一下就動工並升級成功。實作環境：BlogEngine.NET 1.4 實測數據：改善前：未知可行性改善後：2 小時內產出可用 Demo 改善幅度：決策效率提升

Learning Points：

MVP/PoC 思維
最小閉環驗證

Practice Exercise：

基礎：完成 Minimal Widget
進階：加入輸入驗證與樣式
專案：將 Minimal 擴展成可重用模板

Assessment Criteria：

功能完整性：可顯可編可存
代碼品質：簡潔清晰
效能：載入快速
創新性：PoC 可擴展性

Problem Statement（問題陳述）

業務場景：開發者照著印象實作 Widget，但在前台清單中看不到，或加入後沒有渲染。技術挑戰：快速定位是路徑、命名、基底或主題 Zone 問題。影響範圍：排障時間、上線延誤。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

未放在 ~/Widgets/{Name}/ 正確路徑。
類別未繼承 WidgetBase。
主題缺少 WidgetZone。

深層原因：

架構層面：掃描規則是硬約束。
技術層面：動態載入依賴固定相對路徑。
流程層面：缺少檢核清單。

Solution Design（解決方案設計）

解決策略：建立「三件事」檢核：路徑正確、基底正確、Zone 存在。加上「最小可渲染」測試（HelloWorld）。

實施步驟：

檢核與最小化
- 實作細節：建立 HelloWorld Widget 驗證 Zone 與載入
- 預估時間：0.25 人日
日誌與錯誤訊息
- 實作細節：於 LoadWidget 補 Try/Catch + Log
- 預估時間：0.25 人日

關鍵程式碼/設定：

try
{
    var view = LoadControl("~/Widgets/Hello/View.ascx");
    this.Controls.Add(view);
}
catch (Exception ex)
{
    // 記錄日誌，提示開發者
    this.Controls.Add(new Literal { Text = "Widget load error: " + ex.Message });
}

實際案例：作者提到「照 BE 的規矩，繼承指定 CLASS，把檔案放到指定目錄就好了」，反推常見踩雷點即為未遵守規矩。實作環境：BlogEngine.NET 1.4 實測數據：改善前：Widget 不顯示改善後：依檢核快速修復改善幅度：排障時間顯著縮短

Learning Points：

契約優先
最小可用測試法

Practice Exercise：

基礎：做 HelloWorld 驗證 Zone/路徑
進階：導入簡單日誌
專案：寫一份 Widget 發佈檢核清單

Assessment Criteria：

功能完整性：問題能復現且被解
代碼品質：錯誤處理完善
效能：無多餘開銷
創新性：檢核自動化

Problem Statement（問題陳述）

業務場景：過去在樣板上投入大量客製（如舊側欄功能），升級到 1.4 後，不支援 Widget 的主題迫使需要搬遷與重構，如何平滑過渡並保留既有風格與功能。技術挑戰：雙軌並行（先沿用舊樣板上線，再逐步加入 Widget 支援）、避免一次性大改造成風險。影響範圍：上線時程、風險、技術債。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

舊樣板不支援 Widget。
已投入大量版型客製，重做成本高。
需要先上線再逐步改。

深層原因：

架構層面：樣板欠缺可插拔設計。
技術層面：缺少 WidgetZone 與標準樣式。
流程層面：需要分階段遷移策略。

Solution Design（解決方案設計）

解決策略：採分階段遷移。第一階段：保留舊樣板完成升級；第二階段：加入最小 WidgetZone 並把優先級最高的 Box Widget 化；第三階段：全量替換為 Widget 友善結構與 CSS。

實施步驟：

階段一：升級先上線
- 實作細節：保留舊主題，確保核心功能可用
- 預估時間：0.5-1 人日
階段二：最小 WidgetZone + 優先 Box
- 實作細節：先處理廣告/關鍵 Box
- 預估時間：1-2 人日
階段三：全面 Widget 化與樣式統一
- 實作細節：對齊預設主題結構與樣式
- 預估時間：2-3 人日（視規模）

關鍵程式碼/設定：

遷移看板（示意）
- [ ] 新增 RightSidebarZone
- [ ] 轉換 Google Ads
- [ ] 轉換 About
- [ ] 轉換 Latest Comments
- [ ] 清理舊樣板硬嵌區塊

實際案例：作者表示「只好連樣板一起搬過來… 而這個樣版並不支援 Widget 的功能。看來又有得忙了…」即為分階段遷移的現實動機。實作環境：BlogEngine.NET 1.4、自訂樣板實測數據：改善前：升級但無法用 Widgets 改善後：逐步 Widget 化，最終全面採用改善幅度：在可控風險下完成重構

Learning Points：

漸進式重構策略
優先級與價值導向排序

Practice Exercise：

基礎：擇一 Box 完成遷移
進階：完成右側所有 Box 遷移
專案：制定完整的遷移計畫與里程碑

Assessment Criteria：

功能完整性：每階段可獨立交付
代碼品質：無遺留耦合
效能：穩定
創新性：計畫管理與風險控制

案例分類

按難度分類
- 入門級：Case 3, 4, 5, 8, 9, 14, 15
- 中級：Case 1, 2, 6, 7, 10, 11, 12, 16
- 高級：（本次多為應用實作與遷移，未涉及高階分散式/性能極限）
按技術領域分類
- 架構設計類：Case 1, 6, 7, 13, 16
- 效能優化類：Case 10（快取）、部分 2（圖片策略）
- 整合開發類：Case 2（FlickrNet）、Case 8（AdSense）
- 除錯診斷類：Case 15
- 安全防護類：Case 8, 9（安全輸出/腳本）
按學習目標分類
- 概念理解型：Case 1, 5, 13
- 技能練習型：Case 3, 4, 8, 9, 14
- 問題解決型：Case 6, 7, 10, 11, 12, 15, 16
- 創新應用型：Case 2（第三方 API）、Case 10（快取模式）

案例關聯圖（學習路徑建議）

建議先學順序（基礎 -> 應用 -> 遷移/整合 -> 優化/除錯） 1) Case 4（部署與結構） -> 2) Case 5（前台拖拉與 Edit 流程） -> 3) Case 3（編輯器實作） 4) Case 1（Extension vs Widget 選型） -> 5) Case 14（最小 PoC） 6) Case 9（簡介 Widget） -> 7) Case 8（Ads Widget） -> 8) Case 2（Flickr Widget） 9) Case 11（實例設定隔離） -> 10) Case 12（編輯模式 UX） 11) Case 10（快取與效能） -> 12) Case 15（常見踩雷與排障） 13) Case 6（升級 1.4） -> 14) Case 7（主題支援 Widgets） -> 15) Case 13（整體 Box Widget 化） -> 16) Case 16（漸進式遷移完成）
依賴關係
Case 4 是各 Widget 開發的前置（目錄結構/基底）
Case 5/3 是 Widget 可用與可編輯的核心
Case 7 依賴 Case 6（先升級後改主題）
Case 13 依賴 Case 8/9/10（單 Box 完成後再整體化）
Case 16 是 Case 6/7/13 的總結性落地
完整學習路徑建議步驟 A：掌握 Widget 基本規則與操作（Case 4 -> 5 -> 3 -> 1 -> 14）步驟 B：完成常見 Sidebar 功能（Case 9 -> 8 -> 2）步驟 C：掌握設定隔離與 UX 流程（Case 11 -> 12）步驟 D：引入效能與排障能力（Case 10 -> 15）步驟 E：完成升級與主題改造，達成全面 Widget 化（Case 6 -> 7 -> 13 -> 16）

以上 16 個案例可做為從概念到落地、從單點到整體遷移的完整學習藍圖，與原文情境一致且可直接複製到實務教學、專案實作與能力評估中。

[BlogEngine.NET] Widgets

Case #1: 從 Extension 設定困境轉向 Widget 方案

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #2: 使用 FlickrNet 打造相片側欄 Widget

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #3: 為 Widget 建立設定編輯器（Edit User Control）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #4: Widget 正確打包與部署到 ~/Widgets/

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #5: 啟用 1.4 的拖拉與 [Edit] 編輯流程

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #6: 快速升級 BlogEngine.NET 到 1.4 以啟用 Widgets

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #7: 自訂主題不支援 Widget 的相容性改造

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #8: 將 Google 廣告 Box 模組化為 Widget

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #9: 將「安德魯是誰？」簡介區塊 Widget 化

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #10: 最新回應（Latest Comments）以 Widget 呈現

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #11: Widget 實例化設定隔離（Per-instance Settings）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #12: Widget 編輯模式切換與 UX

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #13: 把「硬嵌 Box」整體轉換成 Widget 化運營

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #14: 小步快跑驗證（1-2 小時內完成 PoC）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #15: 遵循 BE 規矩避免「Widget 不顯示」

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #16: 將研究/舊作業平滑遷移到 Widget 生態

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Facebook Pages

AI Synthesis Contents

Edit Post (Pull Request)

Post Directory