Work

[JS tech.] CKeditor Dialog 再起 part 5

在這裡開始之前,我必須告訴你們一件事情,CKeditor 內含的 Event,也就是總共可以被 fire 的監聽事件,分門別類總共有 56 種之多!其中因為 IE 的關係,selectionChange 的監聽事件分出了 IE 專用的 selectionchange(是的,僅大小寫不同),再扣除測試的兩種監聽 someEvent 與 testEvent,還有原本就在 DOM 常見的監聽式以外,CKeditor 所使用的 Event 還是高達 46

Work

[JS tech.] CKeditor 專注本業之 Dialog 超棘手 part 4

寫到這裡,我想說一句公道話,那就是,我之前寫的三篇都可以直接扔進垃圾桶,是一般垃圾不用回收了(翻桌)。編輯器最重要的一個部分,就是自訂的對話框(Dialog),編輯器預設的對話框,跟 FCKeditor 有些許的差異,像是上傳檔案的對話框,在 CKeditor 裡面就沒有在預設工具列內(主要是要提倡跟自家的 CKFinder 合併使用)。 首先呢,在 CKeditor 裡面,所有的對話框都是使用 JavaScript 來產生,所以在設定上並不像以前 FCKeditor 那樣改改他的原始的 html 檔案就能更動對話框,所以關於這一點,

Work

[JS tech.] Ckeditor GOGOGO~~~ 歐雷~歐雷~歐雷~ part 3

這個 CKeditor 有些地方實在是超乎我的想像,他做到了一些並不是編輯器迫切需要的功能,舉例來說,他可以控制 DOM 元件。也許你會覺得,我在編輯器裡面可以控制 DOM 元件並不是什麼壞事,偏偏,他控制的是編輯器以外的 DOM 元件。 當我在測試 Event 的時候,發現這個東西並不只有一種,換句話說,他的 Event 控制分成兩組,一組是自訂的監聽與觸發(類似 ActionScript 那樣),另一組是針對 DOM 元件的特定 events 作觸發(

Work

[JS tech.] Ckeditor 令人詫異的 basic 模式 part 2

接續 上一篇 所提到的基本與完整模式,後來我在測試其他的程式碼的時後發現,所謂的基本(basic)模式,的確是很簡單的五個 JavaScript 檔案就可以做到,但是相對的,犧牲掉的部分卻比我想像中的還要多很多。而最令我震驚的部分是,在基本模式中,呼叫編輯器的 CKEDITOR 的其中一支 prototype: instances 會全數失效,所帶來的後果就是,編輯器本身會完全無法控制(所以才叫做 basic 嗎)? 所以,基本上想要客製化這個編輯器,在官方還沒有釋出(或者不打算釋出)各種 plugins 之間的相依性的話,還是得使用完整的版本(

Work

[JS tech.] CKeditor 萬事起頭一點都不難 - part 1

如果有聽過 FCKeditor 的人,那我想 CKeditor 就一定要換上來用。雖然是同一家公司出品的編輯器,但是用了這麼久的 FCKeditor,我對於他的 API 頁面少成這樣實在有點頭痛,講好聽一點有四頁(驚),講難聽一點只有一頁。自從 CKeditor 推出之後,我一看到他的 API 頁面,差點沒痛哭流涕!這才叫做 API 啊(淚)! CKeditor 是 FCKeditor 的新作品,無論在速度或是 API 上都有很強大的進步。

Chat

[工作筆記] WYSIWYG 編輯器一些零星的瑣碎事情

FCKEditor 算是我從開始接觸所見即所得(WYSIWYG)編輯器,一直用到現在的一個。雖然其中我有嘗試去用別的編輯器,像是 TinyMCE 就是其一。不過,最後用來用去還是回到了 FCKEditor 來,倒不是因為他特別好用,只是習慣問題而已。 這裡有一份線上編輯器的比較表,有興趣可以去看看: http://www.geniisoft.com/showcase.nsf/WebEditors FCKEditor 也不是沒缺點(請看我 上一篇),雖然同樣是採用 IFRAME 做轉換,但是結構上來說並沒有 TinyMCE