2012/09/18

PyHUG 2012/09

PyHUG 九月份主題是 BBS Crawler(bsdconv) 和 Plone

bsdconv 在萬碼奔騰的年代, 處理多種 codecs 和多樣 encodings 是很好的方案。

marr 帶來 Plone 這個 CMS 的簡介和近況。早先我學習 Python 是想用 Plone, 它是一個有感情基礎的 CMS XD

在討論的過程中, 有人對客製強化功能有興趣, Plone 也提供很方便的工具, 我過去也是 跟著既定的脈絡走。但最近使用 SharePointInfoPath 執行一個中大型屬於 CMS 的案子, 所以有其它想法。

首先, 在資料規劃上 … 大量, 多欄, 關聯的資料, 最好的歸宿還是資料庫。CMS 適合擺放目錄式, 多樣(圖檔, pdf, xls, doc, …), 和多版本(v1, v2 的 doc) 的資料。

概念上, 前者適合應用程式(Application), 後者配合流程(Process)。

應用程式處理資料的方式千變萬化, 通用的資料庫仍舊是好選擇。特別是商用資料, 對資料有各種使用方式, 避免瞻前顧後的話, 資料就放在成熟的方案裡頭。

如果說資料庫中表格(Table)的上位是 ERD, CMS 中內容(Content)的上位就是內容型態 (Content Type, CT)。不論 Plone, SharePoint, 或 Jackrabbit 都有相同的概念。通常在 CMS 以檔案系統的概念來做高階規劃 … 建立目錄結構, 接下來就是在目錄下分配使用 CT。一個目錄可使用多個 CT, 也就是先前提到的 多樣性, 而 CT 有不同版本對應不同 Content, 即多版本也順利在 CMS 中成立。 拿程式語言來比擬, CT 像是 Class, Content 是 Object, Folder 是 Collection。

再加上 CMS 對 CT, Folder, Content 有良好權限管理 (Plone 強項, 可類比成 檔案系統的權限設定)。基本上放在 CMS 的資料, 不會被不相干的人取得, 竊認為這是 和資料庫最大區別。

試想 … 流程有多樣電子資料要附帶著, CMS 就是一個很好的載體, 要區分存取權限 也容易。流程若有調整, 造成電子資料的差異, CT 多版本能順利解決這類問題。

應用程式當然也可以做, 但中間規劃, 設計, 與元件 … 太多是重複問題。有些框架有元件, 先不論功能適用, 能像 marr 所言: 最新的 Plone 4 最新版還照顧到 7,8 年前的 Content 就是個門檻了 XD

而許多事務流程系統, 重視流程的彈性, 卻忽略實際工作的要務 … 讓整合困難重重。

說到這裡, 有個題目是 … 表單 (Form) 適合資料庫, 還是 CMS?

不用說很多 MVC 以資料庫為主, 很多 View 概念上就是表單, 甚至 HTML 都有 form 標籤。 考慮實際流程發生的安全問題, 檔案管理, 流程變更要兼容並蓄(新/舊版本), 雖然有各式 各樣的解決方案, 但這些問題放在 CMS … 很自然就被解決掉了。

但在 CMS 裡頭做表單, 問題是 … 簡單的很快, 複雜的費工又很痛(會的人不多)。

我忽略 CMS 的角色有一段時間, 直到用過 InfoPath …

簡單來說 InfoPath 可直覺且快速完成複雜的表單(免除魔術師養成), 然後在 SharePoint 做為一個 CT。安排在特定目錄下, 表單資料存成一個純 XML 檔案, 取得也是一個 XML 檔案。

這種方法接下來的問題是, 要把資料放在資料庫 … 現在資料庫處理 XML/Json 都很強大, 都可以直接吃 XML, 或輸出 XML … 省卻中間的 App Server 或魔術師用的框架, 只要有 SQL 經驗, 輔以一些 XML 的操作就可上手。

整個過程大致是: 

基本上, 在 CMS 的加持下, 免除了表單與資料庫千絲萬縷的關係, 變成有必要才做。

而 OSS 在這方面 … 目前看到的方案還是與資料庫緊密結合 orz

除了一些以 JavaScript 加重瀏覽器負荷的專案, 例如 Backbone-form … 這也是最近嘗試瞭解的題目。

以上是從 Plone 這 CMS 角色延伸想到的 ... 整理下來。從服務式架構的角度, 各組合的角色要清楚, 避免把太多東西塞到某個元件裡。很多時候, 應用開發沒有問題, 畢竟很多功能的差異都可透過努力去彌補, 但清楚的角色有助於系統維護, 另一方面考慮元件的生命週期, 要升級/替代也才能較順利的進行。

另外, 會後聊到 Gmail 保密問題, 我有時會用 GnuPG 套件 … 如果收信人願意的話 XD

組合是 Postbox + Enigmail, Postbox 對 Gmail 的支援良好, 又吃 Mozilla based 的 add-ons (Enimail 提供 GnuPG 功能)。

2012/09/11

嘗試 Require + LiveScript + Backbone

最近想利用 Backbone 的某個套件來做東西, 於是開始摸索 Web 前端。

原先打算用 CoffeeScript 撰寫 Backbone 相關程式碼, 只是 半路 看到更加 有趣的 LiveScript … 馬上改弦易徹。

對 LiveScript 新手, 最初的挑戰 … 不確定寫的是對還是錯。 LiveScript 有個方式是 轉成 JavaScript 來確認 … 雖然有 LiveScript.tmbundle 可為 TextMate/Sublime Text 加持, 由於挺偏好 CoffeeScript-Sublime-Plugin 透過 Command Palette … 選擇 CoffeeScript: Run JavaScript 的方式, 把 CoffeeScript 轉成 JavaScript。於是 混合 LiveScript.tmbundle 和 CoffeeScript-Sublime-Plugin 建立 LiveScript-sublime 專案, 加強 Sublime Text 對 LiveScript 的支援。

接下來是程式碼模組化, CoffeeScript 有 require-cs 擴充 Require 載入 CoffeeScript 能力, 但 LiveScript 沒有。因此參考 require-cs 建立 require-ls, 方便 LiveScript 切分模組。

最後試著把這些組合起來, 以 Backbone 原本的 範例 改寫 為 LiveScript 加上 Require 的版本 … 建立一個 require-ls-backbone 專案記錄這些嘗試。