在這裡開始之前，我必須告訴你們一件事情，CKeditor 內含的 Event，也就是總共可以被 fire 的監聽事件，分門別類總共有 56 種之多！其中因為
IE 的關係，selectionChange 的監聽事件分出了 IE 專用的 selectionchange（是的，僅大小寫不同），再扣除測試的兩種監聽
someEvent 與 testEvent，還有原本就在 DOM 常見的監聽式以外，CKeditor 所使用的 Event 還是高達 46
寫到這裡，我想說一句公道話，那就是，我之前寫的三篇都可以直接扔進垃圾桶，是一般垃圾
不用回收了（翻桌）。編輯器最重要的一個部分，就是自訂的對話框（Dialog），編輯器預設的對話框，跟 FCKeditor 有些許的差異，像是上傳檔案的對話框，在
CKeditor 裡面就沒有在預設工具列內（主要是要提倡跟自家的 CKFinder 合併使用）。
首先呢，在 CKeditor 裡面，所有的對話框都是使用 JavaScript 來產生，所以在設定上並不像以前 FCKeditor 那樣改改他的原始的 html
檔案就能更動對話框，
這個 CKeditor 有些地方實在是超乎我的想像，他做到了一些並不是編輯器迫切需要的功能，舉例來說，他可以控制 DOM
元件。也許你會覺得，我在編輯器裡面可以控制 DOM 元件並不是什麼壞事，偏偏，他控制的是編輯器以外的 DOM 元件。
當我在測試 Event 的時候，發現這個東西並不只有一種，換句話說，他的 Event 控制分成兩組，一組是自訂的監聽與觸發（類似 ActionScript
那樣），另一組是針對 DOM 元件的特定 events 作觸發（
接續 上一篇 [https://blog.hinablue.me/entry/JS-tech-CKeditor-part-1/]
所提到的基本與完整模式，後來我在測試其他的程式碼的時後發現，所謂的基本（basic）模式，的確是很簡單的五個 JavaScript
檔案就可以做到，但是相對的，犧牲掉的部分卻比我想像中的還要多很多。而最令我震驚的部分是，在基本模式中，呼叫編輯器的 CKEDITOR 的其中一支
prototype: instances 會全數失效，所帶來的後果就是，編輯器本身會完全無法控制（所以才叫做 basic 嗎）？
所以，基本上想要客製化這個編輯器，
如果有聽過 FCKeditor 的人，那我想 CKeditor [http://ckeditor.com/]
就一定要換上來用。雖然是同一家公司出品的編輯器，但是用了這麼久的 FCKeditor，我對於他的 API 頁面
[http://docs.fckeditor.net/FCKeditor_2.x/Developers_Guide/JavaScript_API]
少成這樣實在有點頭痛，講好聽一點有四頁（驚），講難聽一點只有一頁。自從 CKeditor 推出之後，
