[BlogEngine.NET] Widgets

問題與答案 (FAQ)

Q&A 類別 A: 概念理解類

Q1: 什麼是 BlogEngine.NET 的 Widget？

• A簡: Widget 是可插入佈景區域、可拖拉與編輯的小工具。以 ASP.NET User Control 製作，放在 ~/Widgets/ 目錄即可使用，自 1.4 版起成為核心功能。
• A詳: 在 BlogEngine.NET 中，Widget 是一種可視化、可重用的小型功能模組，典型用於側欄或頁面預留的「區域」。開發者以 ASP.NET User Control 建置展示介面，並（可選）搭配另一個 User Control 作為「設定編輯面板」。只要遵循 BlogEngine 設計規範（包含繼承指定的 Widget 基底類別）並將檔案置於 ~/Widgets/ 目錄，下次載入頁面時系統即可發現並提供拖拉、排序、編輯與儲存設定等操作。1.4 版將原本散落的側欄模組（如最新回應、廣告、介紹）統一化為可管理的 Widget，讓站長在前台以圖形化方式調整版面而不必改動程式碼，並能透過編輯面板儲存每個 Widget 的個別設定。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q2, A-Q6, B-Q1

Q2: Widget 在部落格中的核心價值是什麼？

• A簡: 降低開發與維護成本，強化模組化與自訂化。站長可拖拉配置、即時編輯，開發者只需撰寫 User Control 即可交付功能。
• A詳: 核心價值在於模組化、重用性與易管理。傳統側欄功能常被硬寫在版面或頁面中，修改與維護困難；Widget 將功能獨立成小模組，具備清楚的輸入（設定）、輸出（渲染）與邊界（放置區域）。站長不必碰程式碼即可調整位置、開關與參數，縮短佈署迭代時間。對開發者而言，利用既有的 ASP.NET User Control 開發經驗，不用學習笨重框架即可快速打造可視小工具。對整站而言，Widget 讓佈景與功能解耦，升級與更換佈景時，只需確保存在相容的 Widget 區域，即可保留既有功能配置，提升系統整體的長期可維護性。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, A-Q14

Q3: 為什麼 BlogEngine.NET 1.4 版引入 Widgets？

• A簡: 將側欄等功能模組化、標準化，提供拖拉、編輯與設定持久化，讓站長以低成本自訂版面與功能。
• A詳: 在 1.4 以前，側欄等「盒子」多半以固定樣板或片段插入，難以在不改碼的前提下調整。1.4 版引入 Widgets 將這些功能統一為可管理的元件，並在前台提供圖形化操作（添加、拖拉、編輯與儲存）。這不僅讓站長能快速調整廣告、介紹文字、最新回應等組件的顯示與位置，也為開發者提供一致的擴充介面：以 User Control 撰寫展示與編輯面板、繼承指定基底類別、放入 ~/Widgets/ 即可。此舉顯著降低客製化成本，提升升級與維護效率，並為日後更多第三方整合（如 FlickrNet 顯示相片）建立穩定的擴充生態。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, A-Q14, B-Q11

Q4: Widgets 與 Extensions 的差異是什麼？

• A簡: Widget 面向視覺與版面，可拖拉與編輯；Extension 側重事件掛勾與後端邏輯，較少直接提供可視介面。
• A詳: Widgets 是可視化的前端小工具，關注如何在頁面上呈現與讓使用者（多為站長）設定；典型放在側欄或頁面區塊，提供拖拉、排序與設定編輯。Extensions 則傾向於後端行為擴充，透過事件或管線在發文、回應、處理流程中插入自訂邏輯，例如過濾留言、重寫連結、注入額外資料等。兩者皆可擴充 BlogEngine，但面向不同：若你的需求是「顯示某內容且讓站長調整外觀或資料來源」，優先考慮 Widget；若需求是「攔截、改寫或增強系統事件流程」，則用 Extension 更合適。實務中也可能結合：Extension 負責提供後端資料，Widget 負責視覺呈現。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q1, A-Q20, D-Q10

Q5: BlogEngine.NET 的 Widgets 與 Microsoft Web Parts 有何異同？

• A簡: 兩者皆為可拖拉的可視模組；Web Parts 架構較重、功能更完整；BlogEngine Widgets 輕量、以 User Control 為主，部署與開發更簡單。
• A詳: 相同點在於：皆提供可視模組、區域化放置、拖拉排序與設定編輯；都旨在提升版面自訂與模組重用。差異在於：Microsoft Web Parts 為 .NET 內建的頁框架，具角色安全、個人化與連接（Web Part Connections）等進階能力，但開發與配置相對複雜。BlogEngine Widgets 專為部落格場景設計，以 ASP.NET User Control 為核心、搭配簡單的檔案與目錄約定（~/Widgets/），開箱即用、部署容易。若你需要企業級個人化與連結機制，Web Parts 更強；若你要快速交付部落格小工具、低學習曲線與輕量維護，BlogEngine Widgets 更適合。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q1, B-Q8

Q6: Widget 的基本構成有哪些元件？

• A簡: 至少包含展示用 User Control，常見另有編輯用 User Control；並遵循 BlogEngine 規範與繼承基底類別，置於 ~/Widgets/。
• A詳: 一個標準的 Widget 通常包含兩個主要部分：1) 展示用 User Control（顯示內容與樣式），2) 編輯用 User Control（呈現設定 UI，儲存自訂參數）。此外會遵循 BlogEngine 的約定，例如：繼承指定的 Widget 基底類別、具備必要的描述資訊（名稱、簡介）、檔案與資料夾結構符合要求、支援載入與儲存設定的機制。當放置於 ~/Widgets/ 後，BlogEngine 會將其加入可選清單並在前台提供加入、拖拉與編輯；若佈景有宣告 Widget 區域，則能在該區域渲染該展示控制項。此分層設計可讓視覺呈現與設定邏輯解耦，便於維護與測試。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q7, B-Q2

Q7: 什麼是 Widget 的編輯面板（Editor）？

• A簡: 編輯面板是供站長調整 Widget 參數的 User Control，透過 UI 儲存設定，影響展示控制項的行為與顯示。
• A詳: 編輯面板是一個獨立於展示層的 User Control，專責提供設定 UI。站長按下前台的 [EDIT] 後，頁面會切換至該編輯控制項，提供表單欄位（如文字框、下拉選單）讓使用者輸入參數，例如 API Key、顯示項目數、標題文字、版面樣式選擇等。當儲存時，編輯面板會呼叫 BlogEngine 的設定保存管道，將參數持久化；展示控制項在下次載入時讀取這些設定來決定呈現內容與外觀。分離編輯面板的好處是：降低展示層複雜度、提升設定 UI 的可維護性，並可在不影響展示的情況下迭代設定功能。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q6, B-Q4

Q8: 為什麼把 Widget 放在 ~/Widgets/ 目錄下？

• A簡: 這是 BlogEngine 的自動發現約定。放在該目錄即可被系統辨識、列出並供前台新增與管理，部署維護較簡便。
• A詳: BlogEngine 採用「約定優於設定」的方式管理 Widgets。將 Widget 檔案（展示控制項、編輯控制項與其資源）放在指定的 ~/Widgets/ 目錄，使系統能以可預測的方式掃描與載入，並統一呈現在前台可用清單中。這帶來多重好處：部署簡單（複製資料夾即上線）、不需為每個 Widget 進行額外註冊、避免與其他網站資源混淆、方便備份與分享。對維運而言，這種固定目錄結構也讓權限管理、資源打包與版本控管更清晰。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q1, B-Q6

Q9: BlogEngine.NET 中常見的 Widget 範例有哪些？

• A簡: 常見有 Google 廣告、站長介紹（關於我）、最新回應、相片牆（如整合 FlickrNet）等側欄功能模組。
• A詳: 部落格最常見的側欄功能幾乎都能以 Widget 形式提供，例如：1) 廣告模組（嵌入第三方 JavaScript 代碼），2) 關於我（靜態或可設定的文字與圖片），3) 最新回應（取用系統資料列出近期留言），4) 熱門文章、分類、標籤雲，5) 外部服務整合，如透過 FlickrNet 抓取公開相片並縮圖顯示、Twitter/社群動態嵌入等。這些 Widget 共同特徵是：獨立於核心文章流程、放在側欄或頁尾等區域、可被站長自由開關與拖拉排序，並透過編輯面板管理各自的參數（顯示數量、來源帳號、樣式）。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, C-Q3

Q10: 什麼是 User Control？為什麼用來實作 Widget？

• A簡: User Control 是 ASP.NET 的可重用 UI 元件。用它寫 Widget 可快速開發、便於設計師與開發者協作，且與 BlogEngine 相容。
• A詳: ASP.NET User Control（.ascx）是可重複使用的 UI 組件，包含標記與程式碼後置。它非常適合封裝中小型視覺功能（如清單、卡片、表單），並可在頁面或其他控制項中重複使用。BlogEngine 選擇以 User Control 作為 Widget 的開發最小單位，原因在於：1) 開發者熟悉、學習曲線低；2) 直接利用 ASP.NET 事件生命週期與伺服器控制項；3) 與設計工具與樣式整合良好；4) 只要遵循 BlogEngine 的 Widget 規約（基底類別、目錄結構），就能被系統自動發現與管理。如此既保留 ASP.NET 的成熟生態，也讓 Widget 製作更為輕量與敏捷。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q6, C-Q1

Q11: 為什麼 Widget 開發「這麼簡單」？

• A簡: 受惠於物件導向與 User Control，遵守繼承規範與目錄約定即可上線，少量程式碼就能完成可拖拉、可編輯的小工具。
• A詳: 簡單的核心在於三件事：1) 架構採約定優於設定（放在 ~/Widgets/ 即被發現）；2) 擴充介面以既有的 User Control 為中心（無須學新框架）；3) 系統提供設定保存與前台操作（拖拉、編輯、儲存）的一致體驗。對開發者來說，僅需專注在兩個部分：展示控制項（如何呈現資料）與編輯控制項（如何收集與保存設定），其它（加入、排序、啟用/停用）交由平台處理。物件導向與組件化思維讓行為與狀態被良好封裝，因此少量程式碼就能交付完整的前端功能。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q10, B-Q7

Q12: 物件導向、OLE/OpenDoc 與 Widget 有何關聯？

• A簡: 三者皆體現組件化思想：以獨立物件協作完成複合工作。Widget 延續這理念於網頁，讓小工具可插拔與重用。
• A詳: OLE（Object Linking and Embedding）與 OpenDoc 代表早期桌面時代的「文件內嵌組件」思想：不同應用的物件能在同一文件或畫面中協作處理資料。Widget 將這樣的組件化理念帶到網頁與部落格環境：每個小工具是獨立的物件（控制項），在頁面上以約定的區域承載，並可被啟用、拖拉、設定與保存狀態。物件導向讓開發者能用清楚的邊界（介面與基底類別）定義 Widget 的行為，達成高內聚、低耦合；同時透過平台提供的容器（頁面與樣板）拼裝出完整體驗。這種延續證明組件化是跨年代、跨平台的可持續設計思想。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: A-Q1

Q13: 何謂 Widget 區域（Zone）或側欄（Sidebar）？

• A簡: 佈景宣告的可放置 Widget 的容器區塊，常見於頁面側欄或頁尾；用來接收、渲染與排序 Widgets。
• A詳: Widget 區域是佈景或版面上預先定義的容器，用於承載多個 Widget。常見放在右側或左側側欄、頁尾等位置。當站長在前台選擇新增或拖拉 Widget，實際就是把某個 Widget 實例放入某一個區域中，並記錄該區域的順序與配置。若佈景未提供任何區域，則無處擺放 Widget，也就無法使用其功能；因此佈景是否支援 Widget 區域，是能否採用 Widgets 的關鍵條件之一。設計良好的佈景會以語意化標記與樣式，讓區域與內部 Widget 呈現一致外觀。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q5

Q14: 1.4 以前與之後的部落格側欄有何不同？

• A簡: 1.4 前多為硬寫側欄內容，調整需改碼；1.4 後改為 Widget 化，可在前台新增、拖拉、編輯並保存設定。
• A詳: 在 1.4 版之前，側欄常以固定樣板或手工插入的區塊實現，更新內容或換位置往往得改前端標記或程式碼，缺乏統一管理。1.4 之後，側欄內容被 Widget 化：站長在前台就能把「最新回應」「關於我」「廣告」等小工具加入到側欄、拖拉排序，並透過 [EDIT] 打開設定面板調整顯示數量、文字或資料來源，變更會被保存並持續生效。這種轉變讓部落格更加模組化與可維護，也鼓勵第三方擴充生態興盛。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q3

Q15: Widget 的設定值如何被保存與載入？（概念）

• A簡: 透過 BlogEngine 提供的設定保存機制，編輯面板儲存參數；展示控制項於載入時讀取，驅動顯示邏輯。
• A詳: 每個 Widget 通常會有一組與實例綁定的設定（如標題、顯示數量、資料來源）。當站長在編輯面板修改並儲存時，Widget 會呼叫平台提供的設定 API 將參數持久化（由系統決定儲存位置與格式），並與該 Widget 實例關聯。展示控制項在初始化或載入階段讀取這些設定，據此決定要渲染哪些資料與採用何種樣式。這種分離讓設定可安全保存、跨頁面重用與升級時保留，且不需在展示層硬編碼。對開發者而言，重點是遵守規約並正確在兩個控制項間傳遞與應用設定。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4

Q16: 佈景主題（樣板）為何可能不支援 Widgets？

• A簡: 舊樣板未宣告 Widget 區域或缺少相應樣式/腳本，導致無法承載、拖拉或正確渲染 Widgets。
• A詳: Widgets 需要佈景預先定義放置區域與相應的外觀樣式。舊樣板若是按 1.4 之前的方式設計，可能沒有任何可放置 Widget 的容器，也未引入必要的樣式規則或腳本行為，因此即使系統支援，也無處添加與渲染。表徵包含：前台無新增按鈕或拖拉手勢、加入後不顯示、顯示破版。解決之道是為樣板加入一個或多個 Widget 區域（側欄、頁尾），提供合適的 HTML 結構與 CSS，並確認前台可交互元素正常工作。升級主題時也應一併測試 Widget 體驗。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, D-Q4, D-Q7

Q17: 為什麼拖拉式配置對部落格管理者重要？

• A簡: 即時重排與視覺化配置可縮短調整周期，無需改碼或佈署，快速試驗內容與版面組合以提升成效。
• A詳: 拖拉式配置讓站長能在內容經營上更敏捷：可隨時把重點功能移至上方、暫時下架不需要的模組、或針對活動調整版面密度。這種即時可見的配置方式，免去改動程式碼與佈署流程，縮短「想法→實驗→觀察→調整」迴圈。對商業目的（如轉換、停留時間）或資訊可達性（如最新消息）都有直接正向影響。更重要的是，它降低非技術人員進入門檻，讓內容團隊可自助完成大部分版面管理工作。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q3

Q18: 使用 FlickrNet 的 Widget 解決了什麼問題？

• A簡: 快速將 Flickr 公開相片抓回並顯示為側欄相片牆，站長透過編輯面板設定帳號、數量等參數即可。
• A詳: FlickrNet 是一個便於呼叫 Flickr API 的 .NET 函式庫。以它為基礎的 Widget 能在不改動核心網站的情況下，快速把相片來源（Flickr 公開相簿）整合到側欄或頁面區域。展示控制項負責抓取相片清單與渲染縮圖；編輯面板則提供輸入 API Key、帳號或欲顯示數量等設定。這樣的 Widget 對攝影或希望加強視覺元素的部落格很實用，且因採 Widget 架構，站長能在前台自由排序、多處重用或暫時停用這個相片牆。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q3, D-Q5

Q19: 升級到 BlogEngine.NET 1.4 會對現有網站帶來什麼影響？

• A簡: 帶來 Widget 能力與前台管理體驗，但舊樣板若不支援 Widget 區域，需調整樣板結構與樣式。
• A詳: 升級到 1.4 的顯著改變，是可用 Widgets 組織側欄與頁面區塊。對有維護中的網站而言，若原樣板未設計 Widget 區域，升級後雖具能力，但前台看不到可用入口或加了也不顯示，需要先改造樣板以支援容器與樣式。若已有大量「硬寫」的側欄內容，建議逐步拆為 Widgets，以便後續拖拉管理。升級流程中也要測試各頁面渲染、確認無腳本衝突與破版情形。總體而言，功能增加、管理更便捷，但需投入一些樣板升級工作。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: D-Q4, B-Q11

Q20: 何時應該選擇 Widget 而非 Extension？

• A簡: 當需求是可視化展示、需前台配置、與版面位置相關時用 Widget；涉及流程攔截或後端邏輯則優先 Extension。
• A詳: 選擇依據在於「是否以視覺呈現為主」。若你要提供一段可見的內容（清單、卡片、廣告、相片）並讓站長在前台調整位置與設定，Widget 是天然選擇，它與佈景與版面密切結合。相反地，若你要在文章流程、回應處理、URL 重寫、驗證等非可視層插入邏輯，Extension 更合適，避免把後端責任塞進前端控制項。兩者可組合：Extension 負責準備資料與掛勾事件，Widget 負責呈現與互動。這樣既保有前端靈活度，也維持後端關注點分離。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q4, D-Q10

Q&A 類別 B: 技術原理類

Q1: BlogEngine.NET 如何發現與載入 Widgets？

• A簡: 依照約定掃描 ~/Widgets/ 目錄，讀取每個 Widget 的控制項與描述，提供清單，並在佈景區域渲染與管理其實例。
• A詳: 系統以目錄約定實作自動發現：當網站啟動或頁面需要渲染 Widgets 時，會讀取 ~/Widgets/ 目錄下的可用 Widget 目錄，根據檔案與規範（例如存在展示/編輯控制項、必要描述）建立 Widget 的可用清單。當使用者在前台選擇某 Widget 並加入到某個區域，系統便記錄該實例與其設定。渲染頁面時，佈景提供的 Widget 區域充當容器，系統依照儲存的順序載入並初始化相應的展示控制項。此流程的核心組件包含：Widget 控制項本身、設定保存與載入機制、前台管理介面與佈景中的容器。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q1, A-Q8

Q2: Widget 的展示控制項與編輯控制項如何協作？

• A簡: 展示控制項負責渲染內容；編輯控制項透過設定 API 持久化參數；展示控制項在載入時讀回設定以決定顯示。
• A詳: 兩者透過「設定」這個資料契約鬆耦合協作。當站長按 [EDIT] 進入編輯面板，編輯控制項會將 UI 欄位（如數量、字串、ID）寫入設定存放；儲存成功後回到展示狀態。展示控制項在初始化或 Page_Load 中讀取設定值，據此決定要抓取何資料（如 Flickr 使用者 ID、公鑰）、顯示幾筆、採哪種樣式等。這種設計避免兩個控制項直接相依，讓它們可以獨立演進；只需遵守設定欄位的名稱與語義即可共同工作。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q6, A-Q7

Q3: 拖拉排序與位置保存背後機制是什麼？

• A簡: 以前端拖拉操作更新 Widget 在區域中的順序與歸屬，提交到伺服器保存，之後渲染按此順序輸出。
• A詳: 前端提供可拖拉的 UI，使用者在區域間或同區域內移動 Widget 時，會產生新的位置與排序資料（例如區域 ID 與序號）。系統將這些改變提交給伺服器持久化。後續渲染時會依據保存結果決定載入順序與容器，確保視覺呈現與管理狀態一致。此流程涉及：前端互動（JS/拖拉行為）、資料模型（區域-Widget 關係與順序）、儲存層（把排列保存為可持續狀態）與渲染層（按序輸出）。這種設計讓版面配置成為資料，因而可回復、遷移與複製。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q17, D-Q2

Q4: Widget 設定的保存與讀取機制（原理）是什麼？

• A簡: 編輯面板經由平台提供的設定 API 將鍵值持久化；展示控制項在初始化/載入時讀回，驅動行為與外觀。
• A詳: 每個 Widget 實例通常維護一組鍵值設定（Key-Value）。當使用者在編輯面板儲存時，Widget 透過平台的設定管道寫入持久層（具體實作由 BlogEngine 決定），並與這個實例綁定。展示控制項在頁面生命週期中取得這組設定，判斷空值或預設值後採用。這種 API 抽象隔離了儲存實作細節，讓開發者只需專注在「要存哪些欄位」與「如何使用設定」；也讓升級或遷移儲存實作時，Widgets 不需改動。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q15, C-Q2

Q5: 佈景主題如何宣告可放置 Widget 的區域？

• A簡: 佈景於頁面/母版中預留容器（如側欄 DIV/PlaceHolder），作為 Widget 的宿主，系統於該處渲染已配置的 Widgets。
• A詳: 為了承載 Widgets，佈景需在版面上預留一個或多個「區域」容器，常見為側欄或頁尾。這些容器以語意化的 HTML 結構與對應樣式呈現，並讓系統能把該區域內的 Widgets 依順序渲染到此。由於 BlogEngine 的前台管理會參照這些區域，若未宣告任何區域，前台就無法新增或顯示 Widgets。良好的做法是：使用清晰的容器結構、設計一致的 Widget 區塊樣式，並在不同視窗大小下保持良好排版。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q16, C-Q4

Q6: ~/Widgets 目錄中的典型檔案與結構為何？

• A簡: 每個 Widget 有獨立資料夾，內含展示 .ascx、編輯 .ascx（可選）與資源（CSS/JS/圖片）；遵守命名與規範便於發現。
• A詳: 依慣例每個 Widget 放在 ~/Widgets/ 下的專屬資料夾，確保資源隔離、易於打包。該資料夾通常包含：展示控制項（如 Widget.ascx 與其程式碼後置）、編輯控制項（如 Edit.ascx）、靜態資源（CSS、JS、圖片）與必要描述資訊。如此結構讓系統掃描時能輕易辨識，部署也只需複製資料夾即可。保持命名一致、避免全域資源衝突與建立 README，有助分享與維護。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q8

Q7: Widget 的繼承與生命週期（原理）是什麼？

• A簡: Widget 繼承平台提供的基底類別，並遵循 ASP.NET 控制項生命週期；於初始化/載入階段綁定資料與應用設定。
• A詳: 雖細節由 BlogEngine 實作，但一般會要求展示控制項繼承某個 Widget 基底類別，以取得設定、識別資訊與平台整合能力。控制項仍遵循 ASP.NET User Control 的事件生命週期（Init、Load、PreRender 等），於適當階段讀取設定、載入資料並渲染。編輯控制項亦類似，負責將 UI 值寫回設定。這種繼承與生命週期配合，使 Widget 能與平台管理介面、設定保存與佈景渲染流程順暢對接。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q11, C-Q1

Q8: BlogEngine Widgets 與 Web Parts 的主機與安全模型差異？

• A簡: Web Parts 有較完整主機與安全/個人化模型；BlogEngine Widgets 輕量，聚焦部落格場景，部署簡單、學習曲線低。
• A詳: Web Parts 由 ASP.NET 提供，具備角色/個人化、連接等進階能力，但需要相對重的設定與主機控制。BlogEngine Widgets 則將焦點放在部落格內容展示與版面管理，以最小化的規約（User Control、目錄約定、簡單設定）提供直覺的拖拉與編輯體驗。安全與個人化在 BlogEngine 多半由平台整體處理（如誰能編輯），而非每個 Widget 自行實作。這讓部落格的擴充更輕盈，適合頻繁佈署與非技術站長操作。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: A-Q5

Q9: 為何要將展示層與設定層分離？

• A簡: 降低耦合、提升維護性。展示專注渲染，編輯專注收集與保存設定，兩者以設定契約溝通。
• A詳: 分離讓每一部分責任單一：展示控制項專心把資料以良好樣式呈現，不被設定 UI 邏輯干擾；編輯控制項專心提供使用者友善的設定界面與驗證。兩者以統一的設定契約交換資料，彼此可獨立演進與測試。此設計也改善安全性與穩定性：即使設定 UI 出錯，展示層仍可採預設值穩定運作；不同使用情境下（如行動版或無 JS）也可替換展示層而不動設定機制。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q6, C-Q2

Q10: 整合外部 API（如 FlickrNet）時的資料流與效能考量？

• A簡: 編輯面板收集 API 參數；展示層呼叫外部 API 取資料、轉為展示模型並渲染；可用快取減少外呼頻率。
• A詳: 資料流典型為：1) 編輯面板輸入 API Key/來源 ID/數量，保存設定；2) 展示層於載入讀取設定，呼叫外部 API；3) 將回應轉為內部展示模型（縮圖 URL、標題、連結），綁定至 UI；4) 遇錯誤顯示友善訊息並採預設。效能面建議加入快取（時間/條件），避免每次渲染都外呼；也可在非同步背景抓取資料、失敗時退回上次成功資料。網路錯誤與配額限制須處理超時與限流，避免拖慢頁面。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: A-Q18, D-Q9

Q11: 版本升級對 Widgets 的相容性影響（原理）？

• A簡: 升級可能改變前台管理與佈景需求；舊樣板需補上 Widget 區域與樣式；Widget 若遵守規約，多半可相容。
• A詳: 平台升級（如 1.4）常引入新管理方式與渲染流程。只要 Widget 遵守官方規約（基底類別、設定 API、目錄約定），核心相容性通常良好；較常見的相容問題反而在佈景：未提供區域、樣式衝突、JS 行為不匹配，導致無法拖拉或顯示異常。此外若平台調整設定保存策略，也需驗證編輯面板讀寫是否仍正確。最佳實踐是在測試環境先行驗證視覺、互動與設定保存，再逐步推上線。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q19, D-Q4

Q12: 不支援 Widgets 的樣板如何影響渲染流程？

• A簡: 無區域即無容器，Widgets 不會出現在頁面；即便加入成功，渲染也找不到目標位置而被隱形。
• A詳: Widgets 必須掛載在佈景宣告的區域內才能渲染。若樣板未提供任何區域，管理介面可能仍允許「新增」，但渲染階段因找不到對應容器而無輸出；或輸出到非預期位置，造成破版。即便渲染成功，缺少樣式會導致外觀錯亂。修復之道是明確在樣板加入容器結構、設計對應樣式，並測試前台管理操作（新增、拖拉、編輯）是否正常。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q16, D-Q7

Q&A 類別 C: 實作應用類（10題）

Q1: 如何建立最簡單的 Hello Widget？

• A簡: 建立資料夾於 ~/Widgets/，新增展示用 .ascx（輸出文字），依規約繼承基底類別並佈署，即可於前台加入與拖拉。
• A詳:
  • 具體實作步驟: 1) 建立資料夾 ~/Widgets/HelloWidget/ 2) 新增 HelloWidget.ascx 與程式碼後置，輸出簡單文字 3) 讓控制項繼承 BlogEngine 規定的 Widget 基底類別 4) 佈署資料夾到伺服器，前台新增並測試
  • 關鍵程式碼片段或設定（示意）:
    Hello, Widget!
  • 注意事項與最佳實踐:
    • 保持資料夾結構乾淨；命名清楚
    • 驗證佈景已有可放置區域
    • 先從無設定的展示 Widget 起步，確認載入流程
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q6, B-Q7

Q2: 如何為 Widget 新增編輯面板並保存設定？

• A簡: 新增 Edit.ascx 提供表單，透過平台設定 API 寫入參數；展示控制項在載入時讀取設定並套用。
• A詳:
  • 具體實作步驟: 1) 在 ~/Widgets/MyWidget/ 新增 Edit.ascx，放入標題、數量等欄位 2) 在儲存事件中呼叫平台提供的設定保存方法（示意） 3) 在展示控制項載入時讀取設定鍵值，套用邏輯或預設值
  • 關鍵程式碼片段或設定（偽代碼）: // Edit.ascx.cs (偽代碼) void Save_Click(…) { Settings[“Title”] = txtTitle.Text; Settings[“Count”] = txtCount.Text; SaveSettings(Settings); } // Widget.ascx.cs (偽代碼) void Page_Load(…) { var title = GetSetting(“Title”, “預設標題”); var count = int.Parse(GetSetting(“Count”, “5”)); BindData(count); lblTitle.Text = title; }
  • 注意事項與最佳實踐:
    • 欄位驗證與預設值必備
    • 變更設定後重新載入展示
    • 避免在展示層直接存設定
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q7, B-Q4

Q3: 如何用 FlickrNet 做出相片牆 Widget？

• A簡: 展示控制項用 FlickrNet 取回相片清單並綁定縮圖；編輯面板輸入 API Key/使用者 ID/顯示數量等並保存。
• A詳:
  • 具體實作步驟: 1) 參考 FlickrNet 程式庫並設定 API Key 2) 編輯面板輸入使用者 ID、顯示張數 3) 展示控制項於 Page_Load 讀取設定，呼叫 FlickrNet API 取得公開相片 4) 綁定縮圖與連結至 Repeater/ListView
  • 關鍵程式碼片段（示意）: // Widget.ascx.cs（示意） var apiKey = GetSetting(“ApiKey”,””); var userId = GetSetting(“UserId”,””); var take = int.Parse(GetSetting(“Count”,”6”)); var flickr = new Flickr(apiKey); var photos = flickr.PeopleGetPublicPhotos(userId, 1, take); rpt.DataSource = photos; rpt.DataBind();
  • 注意事項與最佳實踐:
    • 錯誤處理（API 失敗時顯示替代內容）
    • 加入快取降低外呼
    • 遵守 Flickr 使用規範
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q18, B-Q10

Q4: 如何讓佈景主題支援 Widget 區域？

• A簡: 在佈景（母版或頁面）加入區域容器，提供語意化 HTML 與樣式，讓系統能在該區渲染 Widgets。
• A詳:
  • 具體實作步驟: 1) 打開佈景的母版頁或版面檔 2) 在側欄位置加入容器（如 div/PlaceHolder） 3) 設計 .widget 區塊的通用樣式 4) 佈署並在前台新增 Widget 測試
  • 關鍵程式碼片段（示意）:
  • 注意事項與最佳實踐:
    • 測試不同螢幕寬度
    • 保持 Widget 外框樣式一致
    • 確保語意化與可存取性
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, D-Q7

Q5: 如何將舊樣板升級以支援拖拉式 Widgets？

• A簡: 補上 Widget 區域與樣式，檢查前台互動是否正常；將舊側欄內容逐步改寫為 Widgets。
• A詳:
  • 具體實作步驟: 1) 盤點舊側欄內容，規劃對應 Widgets 2) 於佈景加入一到多個 Widget 區域容器 3) 加入必要 CSS 讓 Widget 外觀一致 4) 移除硬寫內容，改為於前台新增 Widgets
  • 關鍵設定（示意）: /* site.css */ .widget-zone { padding: 8px; } .widget { margin-bottom: 12px; border: 1px solid #ddd; }
  • 注意事項與最佳實踐:
    • 逐頁驗證渲染與拖拉
    • 先在測試環境試運轉再上線
    • 保留回退方案
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q16, D-Q4

Q6: 如何在前台提供 [EDIT] 以開啟 Widget 編輯面板？

• A簡: 登入具權限的使用者時，系統會提供編輯入口。可在 Widget 模板中呈現編輯圖示或連結以啟用編輯模式。
• A詳:
  • 具體實作步驟: 1) 確認登入使用者有管理權限 2) 在版面提供切換「編輯模式」的入口 3) 編輯模式下，每個 Widget 旁顯示 [EDIT]
  • 關鍵程式碼片段（示意）: <% if (User.Identity.IsAuthenticated) { %> EDIT <% } %>
  • 注意事項與最佳實踐:
    • 僅對具權限者顯示
    • 避免被快取隱藏或誤顯示
    • 編輯後導回展示模式
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q7, D-Q3

Q7: 如何調整 Widget 的排序與固定位置？

• A簡: 進入前台編輯模式，拖拉 Widget 至目標區域並放開，系統會保存順序；必要時可鎖定某些位置。
• A詳:
  • 具體實作步驟: 1) 切換到編輯模式 2) 拖曳 Widget 至新位置或區域 3) 儲存或套用變更，驗證渲染順序
  • 關鍵設定或提示:
    • 某些佈景會提供「置頂」類樣式，視覺上固定首位
  • 注意事項與最佳實踐:
    • 調整後清除瀏覽器/站台快取以驗證
    • 測試行動版拖拉體驗
    • 大量 Widget 建議分區整理
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q3, D-Q2

Q8: 如何部署自製 Widgets 到正式環境？

• A簡: 將 Widget 資料夾完整複製到 ~/Widgets/；檢查權限與參考資源路徑；於前台新增並測試設定。
• A詳:
  • 具體實作步驟: 1) 打包 ~/Widgets/MyWidget/（含 .ascx、資源） 2) 上傳至正式站相同路徑 3) 驗證資源（CSS/JS/圖片）路徑 4) 以管理者登入前台新增並測試
  • 關鍵設定:
    • 若 Widget 需寫入設定，確保相關儲存路徑有寫入權限（依平台而定）
  • 注意事項與最佳實踐:
    • 先佈署到預備環境測試
    • 維持資料夾命名與版本資訊
    • 減少對全域資源的相依
• 難度: 初級
• 學習階段: 核心
• 關聯概念: D-Q1

Q9: 如何封裝 Widget 以便分享與重用？

• A簡: 以資料夾為單位打包（含展示/編輯控制項與資源），附上 README、版本與需求說明，避免全域衝突。
• A詳:
  • 具體實作步驟: 1) 整理 ~/Widgets/MyWidget/ 內容，移除不必要檔案 2) 加入 README（需求、設定方式、截圖） 3) 標示版本兼容（支援 BlogEngine 版本） 4) 打包成壓縮檔供下載
  • 關鍵設定或建議:
    • 使用命名空間與前綴避免 CSS/JS 衝突
  • 注意事項與最佳實踐:
    • 不含硬編碼環境路徑
    • 文件化設定鍵值名稱
    • 附上變更記錄
• 難度: 初級
• 學習階段: 核心
• 關聯概念: B-Q6

Q10: 如何為 Widget 增加多語系（在地化）支援？

• A簡: 使用 .NET 資源檔（.resx）或字串資源集中管理文案，依文化設定載入對應語系，避免硬編碼字串。
• A詳:
  • 具體實作步驟: 1) 為 Widget 建立資源檔（如 Strings.resx、Strings.zh-TW.resx） 2) 在 .ascx 使用 <%$ Resources:Strings, Title %> 參考字串 3) 在程式碼後置以 ResourceManager 讀取
  • 關鍵程式碼片段（示意）: lblTitle.Text = Resources.Strings.Title;
  • 注意事項與最佳實踐:
    • 設定文化（Culture/UICulture）一致
    • 編輯面板欄位標籤也要在地化
    • 避免把可翻譯字串硬寫在程式碼
• 難度: 中級
• 學習階段: 進階
• 關聯概念: A-Q9

Q&A 類別 D: 問題解決類（10題）

Q1: Widget 未出現在前台清單或頁面怎麼辦？

• A簡: 檢查是否放在 ~/Widgets/、檔案結構與命名、佈景是否有 Widget 區域；重新整理、檢視權限與錯誤記錄。
• A詳:
  • 問題症狀描述: 新增的 Widget 沒有出現在可用清單，或加入後頁面不渲染。
  • 可能原因分析: 未置於 ~/Widgets/；缺漏展示控制項；命名/結構不符規約；佈景無區域；資源讀取錯誤。
  • 解決步驟: 1) 確認資料夾路徑與內容完整 2) 驗證展示 .ascx 是否可載入 3) 檢查佈景是否已有區域 4) 查看站台錯誤日誌
  • 預防措施: 遵守目錄結構、撰寫 README、先在測試站驗證再上線。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: A-Q8, B-Q6

Q2: 拖拉排序不生效或無法保存，怎麼辦？

• A簡: 檢查前端腳本是否載入、瀏覽器阻擋、權限與保存失敗；清除快取後再試，查看錯誤日誌確認存檔。
• A詳:
  • 問題症狀描述: 可拖拉但重新整理順序恢復；或完全無法拖動。
  • 可能原因分析: JS/樣式衝突；未登入編輯模式；儲存權限不足；伺服器端保存失敗；快取干擾。
  • 解決步驟: 1) 確認已進入編輯模式 2) 檢查瀏覽器主控台錯誤 3) 驗證伺服器保存（權限/錯誤） 4) 清除快取再測
  • 預防措施: 主題 JS 命名空間隔離、保存後顯示成功提示、建立端對端測試。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3

Q3: [EDIT] 編輯面板打不開或設定不會保存，怎麼辦？

• A簡: 檢查是否有編輯控制項、欄位驗證錯誤、權限與設定 API 呼叫；以預設值與簡化表單測試。
• A詳:
  • 問題症狀描述: 按下 [EDIT] 無反應或空白；填寫後儲存無效。
  • 可能原因分析: 缺少編輯 .ascx；儲存事件未綁定；設定 API 呼叫失敗；權限不足；表單驗證阻擋。
  • 解決步驟: 1) 確認 Edit.ascx 存在且可載入 2) 檢查儲存事件是否觸發 3) 以日誌/偵錯檢視設定保存 4) 測試最小表單（只一欄）隔離問題
  • 預防措施: 在展示與編輯分支都寫入單元測試；建立預設值與錯誤回退。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q7, C-Q2

Q4: 升級到 1.4 後版面顯示異常或 Widgets 失效？

• A簡: 舊樣板未支援 Widget 區域或樣式衝突。先更新佈景（加入區域與 CSS），逐步轉換舊側欄為 Widgets。
• A詳:
  • 問題症狀描述: 升級後側欄空白、拖拉無效、破版。
  • 可能原因分析: 样板無區域；樣式/腳本與新管理介面不相容；Widget 舊版相依。
  • 解決步驟: 1) 加入 Widget 容器與通用樣式 2) 移除舊硬寫側欄，改用 Widgets 3) 驗證拖拉與編輯流程 4) 檢視日誌修正相依錯誤
  • 預防措施: 測試環境演練、版本管控、回退策略。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q16, B-Q11

Q5: FlickrNet 相片牆不顯示圖片或報錯？

• A簡: 檢查 API Key、使用者 ID、網路/防火牆與配額；加入錯誤處理與快取，避免外呼失敗拖慢頁面。
• A詳:
  • 問題症狀描述: 側欄空白或顯示錯誤訊息；載入緩慢。
  • 可能原因分析: 憑證錯誤；使用者 ID 錯；API 超時或配額耗盡；連線被阻擋。
  • 解決步驟: 1) 驗證設定（API Key、UserId） 2) 以工具測試 API 連線 3) 加入例外處理與替代 UI 4) 使用快取降低外呼頻率
  • 預防措施: 設定重試與快取；監控錯誤率；遵守 API 限制。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q3

Q6: Widget 相依的外部資源（JS/CSS/圖片）載入失敗？

• A簡: 確認相對/絕對路徑、佈署資源完整與 CDN 可達；避免全域衝突，使用命名空間與前綴。
• A詳:
  • 問題症狀描述: 版面走樣、互動失效或 404。
  • 可能原因分析: 路徑錯誤；資源漏佈署；CDN 阻擋；命名衝突。
  • 解決步驟: 1) 檢查瀏覽器網路面板 2) 修正資源路徑或改用內嵌資源 3) 改用可靠 CDN 或自備資源 4) 命名空間化 CSS/JS
  • 預防措施: 建立佈署清單；自動化檢查資源完整；盡量避免跨 Widget 全域覆寫。
• 難度: 初級
• 學習階段: 核心
• 關聯概念: C-Q9

Q7: 如何判斷佈景不支援 Widgets 並修復？

• A簡: 若無新增入口或新增後不顯示，多半缺 Widget 區域。加入容器與樣式，驗證前台拖拉與編輯。
• A詳:
  • 問題症狀描述: 前台看不到新增/拖拉 UI；新增後無渲染。
  • 可能原因分析: 樣板未宣告容器；CSS 隱藏或衝突。
  • 解決步驟: 1) 檢視樣板 HTML 有無區域 2) 加入容器與通用樣式 3) 測試新增、拖拉、編輯
  • 預防措施: 主題開發時預留至少一個區域；文件化主題相容性。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: C-Q4

Q8: Google 廣告或第三方代碼在 Widget 中被過濾或不執行？

• A簡: 確認以 Literal 呈現、避免 HTML 編碼；放置於展示層並確保腳本時機；檢查 CSP 或安全設定。
• A詳:
  • 問題症狀描述: 廣告不顯示、script 未執行或被字元轉義。
  • 可能原因分析: 以伺服器控制項輸出導致 HTML 編碼；腳本載入時機錯；CSP/安全限制。
  • 解決步驟: 1) 用 Literal 控制項輸出原始 HTML 2) 確保腳本在適當位置/時機執行 3) 檢查站台安全政策
  • 預防措施: 將第三方代碼封裝為部分檢視；標示依賴與限制；測多瀏覽器。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q1

Q9: 多個 Widgets 導致效能不佳，如何優化？

• A簡: 針對外部資料加快取與非同步載入，減少重複請求；控制顯示數量與圖片大小，避免阻塞渲染。
• A詳:
  • 問題症狀描述: 首屏渲染慢、頻繁外呼。
  • 可能原因分析: 每個 Widget 都外呼；無快取；圖片過大；JS/CSS 過多。
  • 解決步驟: 1) 對外部 API 增加快取與錯誤回退 2) 合併/壓縮資源；延遲非關鍵載入 3) 控制清單數量與圖片尺寸
  • 預防措施: 以效能預算設計 Widgets；監測與告警；定期審視第三方相依。
• 難度: 中級
• 學習階段: 進階
• 關聯概念: B-Q10

Q10: Widgets 與 Extensions 功能重疊或衝突，如何診斷？

• A簡: 明確分工：視覺顯示交給 Widget、流程邏輯由 Extension 處理；關閉一方比對行為，調整責任邊界。
• A詳:
  • 問題症狀描述: 同一功能被兩處處理，造成雙重輸出或行為互斥。
  • 可能原因分析: 設計時未切清關注點；兩者同時修改相同資料或 DOM。
  • 解決步驟: 1) 做最小重現，單獨啟用/停用比對 2) 決定責任歸屬（顯示 vs 邏輯） 3) 移除重疊或以事件順序協調
  • 預防措施: 設計前先劃分 Widget 與 Extension 邊界；為每個元件寫明責任與依賴。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q4

學習路徑索引

• 初學者：建議先學習哪 15 題
  • A-Q1: 什麼是 BlogEngine.NET 的 Widget？
  • A-Q2: Widget 在部落格中的核心價值是什麼？
  • A-Q3: 為什麼 BlogEngine.NET 1.4 版引入 Widgets？
  • A-Q6: Widget 的基本構成有哪些元件？
  • A-Q7: 什麼是 Widget 的編輯面板（Editor）？
  • A-Q8: 為什麼把 Widget 放在 ~/Widgets/ 目錄下？
  • A-Q9: BlogEngine.NET 中常見的 Widget 範例有哪些？
  • A-Q10: 什麼是 User Control？為什麼用來實作 Widget？
  • A-Q13: 何謂 Widget 區域（Zone）或側欄（Sidebar）？
  • A-Q14: 1.4 以前與之後的部落格側欄有何不同？
  • A-Q17: 為什麼拖拉式配置對部落格管理者重要？
  • B-Q5: 佈景主題如何宣告可放置 Widget 的區域？
  • C-Q1: 如何建立最簡單的 Hello Widget？
  • C-Q7: 如何調整 Widget 的排序與固定位置？
  • D-Q1: Widget 未出現在前台清單或頁面怎麼辦？
• 中級者：建議學習哪 20 題
  • A-Q4: Widgets 與 Extensions 的差異是什麼？
  • A-Q11: 為什麼 Widget 開發「這麼簡單」？
  • A-Q15: Widget 的設定值如何被保存與載入？（概念）
  • A-Q16: 佈景主題（樣板）為何可能不支援 Widgets？
  • A-Q18: 使用 FlickrNet 的 Widget 解決了什麼問題？
  • A-Q19: 升級到 BlogEngine.NET 1.4 會對現有網站帶來什麼影響？
  • A-Q20: 何時應該選擇 Widget 而非 Extension？
  • B-Q1: BlogEngine.NET 如何發現與載入 Widgets？
  • B-Q2: Widget 的展示控制項與編輯控制項如何協作？
  • B-Q3: 拖拉排序與位置保存背後機制是什麼？
  • B-Q4: Widget 設定的保存與讀取機制（原理）是什麼？
  • B-Q6: ~/Widgets 目錄中的典型檔案與結構為何？
  • B-Q7: Widget 的繼承與生命週期（原理）是什麼？
  • B-Q11: 版本升級對 Widgets 的相容性影響（原理）？
  • C-Q2: 如何為 Widget 新增編輯面板並保存設定？
  • C-Q4: 如何讓佈景主題支援 Widget 區域？
  • C-Q5: 如何將舊樣板升級以支援拖拉式 Widgets？
  • C-Q8: 如何部署自製 Widgets 到正式環境？
  • D-Q2: 拖拉排序不生效或無法保存，怎麼辦？
  • D-Q3: [EDIT] 編輯面板打不開或設定不會保存，怎麼辦？
• 高級者：建議關注哪 15 題
  • A-Q12: 物件導向、OLE/OpenDoc 與 Widget 有何關聯？
  • B-Q8: BlogEngine Widgets 與 Web Parts 的主機與安全模型差異？
  • B-Q9: 為何要將展示層與設定層分離？
  • B-Q10: 整合外部 API（如 FlickrNet）時的資料流與效能考量？
  • C-Q3: 如何用 FlickrNet 做出相片牆 Widget？
  • C-Q9: 如何封裝 Widget 以便分享與重用？
  • C-Q10: 如何為 Widget 增加多語系（在地化）支援？
  • D-Q4: 升級到 1.4 後版面顯示異常或 Widgets 失效？
  • D-Q5: FlickrNet 相片牆不顯示圖片或報錯？
  • D-Q6: Widget 相依的外部資源（JS/CSS/圖片）載入失敗？
  • D-Q7: 如何判斷佈景不支援 Widgets 並修復？
  • D-Q8: Google 廣告或第三方代碼在 Widget 中被過濾或不執行？
  • D-Q9: 多個 Widgets 導致效能不佳，如何優化？
  • D-Q10: Widgets 與 Extensions 功能重疊或衝突，如何診斷？
  • A-Q5: BlogEngine.NET 的 Widgets 與 Microsoft Web Parts 有何異同？