PDF Forms

近來關注著表單的相關方案, 除了 Web(眾多框架, backbone-forms), XML(XForms, InfoPath, XUL) … 前陣子逛軟體商店, 才發現有處理 PDF 表單這類 App。

搜尋相關資源, 整理一下 …

雖然系出 Adobe, 卻也不一定需要 Adobe 官方指定工具, 就能從頭到尾、從建立到處理, 完成所有工作。

特點

和 Web, XML 方案要一整個系統最大的差別, 在於 PDF 的表單只要單檔就可運作。

1. 方便移動

PDF 表單除了只要單檔, 和 PDF 一樣, 不論行動設備或各種常見的作業系統都通行。

在 OS X 上的 Preview 可直接填寫。

另一個觀點是能離線作業 … 得以各別填妥表單再傳送處理。

2. 容易讀取

不論對人與電腦都方便。

PDF 可輸出的樣式彈性很大, 幾乎是報表方案的代名詞。好讀自然不再話下, 只要有適當的設計規劃。再加上一些欄位就成為 PDF Forms, 立即讓人填寫。

讀取表單內容, 可利用 pdftk 直接讀出資料, 毋須寫程式也可使用 … 在下一段介紹用法。

實作

很多介紹, 是以寫程式來產生 PDF 表單, 後續處理表單資料也要額外程式 … 其實不一定需要, 這些工作不寫程式也能達成。

1. 建立表單 PDF Forms

在 OS X 有 PDFpenPro, PDFClerk Pro, PDF Nomad 可替 PDF 加上表單欄位。

開放源碼 OpenOffice(使用版本 3.4.1), 則可在各平台直接建立 PDF 表單。步驟大致如下:

a. 新增 XML 表單

b. 建立表單項目

在下面的範例, 塞一張圖檔、加一些欄位, 額外使用淡紅色標示欄位名稱。

建妥表單, 再到下一步。

c. 輸出 PDF 表單

d. PDF 表單選項

e. PDF 表單檔名

完成以上步驟, 應該能順利產生 PDF 表單: fruit_order.pdf 檔案。

下載: fruit_order.odt(無法預覽, 請選擇下載), fruit_order.pdf(線上看有點怪, 下載後 ok)。

2. 取出資料

a. 填寫表單資料

使用 Preview 按上面 PDF 表單給定欄位, 填入各項資料。

填入的資料會存入該 pdf 檔案中。

b. 讀取表單資料

使用 pdftk, 如果檔案放在 ~/Desktop/fruit_order.pdf, 執行如下指令:

$ pdftk ~/Desktop/fruit_order.pdf dump_data_fields_utf8 output -

就可將表單資料輸出到 stdout, 或把 - 改為檔名, 選擇輸出到特定檔案。

和先前 b. 建立表單項目 步驟比較, 可看出 欄位名稱 (FieldName) 和 填寫資料 (FieldValue) … 很容易對上。

3. 佈置 PDF 表單

從上面的介紹, 瞭解 PDF 表單 建立, 填寫, 讀取 方式, 接下來看看怎麼安置這些 PDF 表單檔案。

a. 電子郵件

PDF 放在網站上提供下載, 或以電子郵件傳給需要填表單的人。

在 PDF 表單裡頭標注, 填寫完寄給 foo@jia-side.org … 即可完成表單發送、接收的程序。

只是收到 PDF 檔案後會怎樣被處理, 全取決於經辦人員。

b. 檔案分享

適合組織內區域網路中檔案共享, 或使用網際網路檔案服務的方式 … 也就是特定群組內的檔案分享。

在檔案相關系統中, 安排 PDF 表格處理方式的各種目錄。例如: 所有表單的 樣板目錄, 處理中目錄, 完成目錄, 以及最後流入按年份分門別類的 庫存目錄, …

使用大部份人都熟悉的方式, 不同工作在不同目錄間流動, 即可完成許多原先紙本的工作。

c. 內容管理 + 流程系統

基本上, 是前個項目 b. 檔案分享 的進階版 … 概念相同, 但所有動作自動化。

• 樣板目錄 中, 各表單的版本由內容管理區分。
• 新填表單送入 收件目錄, 由流程系統分派給經辦人員。
• 表單處理的特定過程, 皆由流程系統安排。(可考慮資料檢核)
• 處理完成, 按流程安排的步驟放入 完成目錄 中, 供相關人員瀏覽。
• 老舊檔案的時間屆存檔年份, 內容管理負責移到 庫存目錄 備查。

用途

表單是許多組織行動的基礎, 單純表單的角色, 卻常被使用系統與人力資源所左右。

複雜的系統, 其本身往往就需要很多專業人士來維持。

從頭打造的應用系統, 建立/維護也是個問題, 總不成每每來個衝刺。

使用 PDF 表單, 有機會突破這些罩門。

• 能操作文書軟體, 就能建立/維護表單。
• 不需 Web 專業, 也可在表單中盡量放入必要訊息。(參考高鐵轉乘服務的PDF檔)
• 讀取表單內輸入項目的資料, 只要工具, 不用寫程式。

使用方面 PDF 表單也近似紙本表單, 能高亮(Highlight)標示、張貼備忘(Note) …

再者, 若打通檔案的流通, 透過智慧手機、平板設備處理 PDF 表單, 會更接近真實填寫表單, 包括簽名。

PyHUG 2012/09

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

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

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

在討論的過程中, 有人對客製強化功能有興趣, Plone 也提供很方便的工具, 我過去也是 跟著既定的脈絡走。但最近使用 SharePoint 和 InfoPath 執行一個中大型屬於 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 功能)。

嘗試 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 專案記錄這些嘗試。

集中/聚眾/集眾開發

一直從事軟體開發工作, 其中不論參與產業, 各類技術, 團隊規模, 時間長短, 雖有各有不同, 皆是解決客戶問題為主, 也都是專案的型態 … 而專案執行方式也各有不同, 從古早到近年流行的, 或多或少都參與過。總的來說, 都是由外而內的驅使著開發者, 必須針對客戶的需求做處理, 做回應。

從剛開始是廠商, 標準, 或方法的傳聲筒, 到現在能夠提出各式各樣的嘴砲意見。這是 … 馬齒徒長!!??

由外而內的改變, 雖然邊拉距邊有進展, 但聽說真正的成長是由內而外。因此, 開始思考在執行專案時, 發生衝突到最後調和的事件。嗯, 這篇不是談技術, 因為技術最好的歸宿就是被消滅; 也不是談業務, 因世代更迭的業務, 總是來來去去。目標是整理一下開發大環境的差別, 及相關的影響。最後歸納為, 開發者正經歷集中開發(Central), 聚眾開發(Clustered), 與集眾開發(Crowded)的不同世代。

把紅點視為一開發單位, 紅點散落位置區分了不同的方式:

• 集中開發: 紅點集中在一起, 為共同目標而努力。
• 聚眾開發: 紅點聚落各有長處, 分工聚落各有發揮, 但聚落合作才能完成目標。
• 集眾開發: 當群體進展到某個程度, 個別單位縱使降低對資源的要求, 還是能達成目標。

從硬體, 軟體, Java 舉例來說:

• 硬體: 古早到現在 IBM 的角色, 毋庸置疑; 台灣著名的就是電腦組件聚落; 蘋果則近年來讓電腦取代寵物的地位方面功績卓著。
• 軟體: Oracle 專長打造資料的家; MS 建立的聚落嚴有許多 … 作業系統, 企業應用, 遊戲; SF 雖然漸漸被取代, 但卻是讓大眾發表分享源碼, 方便交流的起點。
• Java: Sun 早先前集中資源打造出跨世紀的 JVM, JDK; Apache 以 Web, Services 甚至雲端著名, 近來常做撫養托孤業務; Hadoop 是 Apache 其中一個聚落, 但更能表現集眾開發, 為此獨立出來。

先看 Apache 與 Sourceforge, A 和 S 都是開放源碼的重鎮, 但 A 是會員制, S 則隨開隨用。Apache 能到頂層(top level)的專案, 幾乎都可視為一個聚落, 聚集著對專案有興趣的公司或個人。開始先在論壇, 事例追蹤上參與, 被認同後才賦予擔負工作的身份。A 要去瞭解, 要去參與, 而 S 只要名稱不同, 很快就能開個專案, 我還是我。在早期 S 能聚集的是本身具備吸引力的專案, A 透過組織方式更能推動發展。

發展到一個階段, 開發不只著重開發者的角色。以社群類處理的使用者數量來說, 是早先集中式商業公司嘗試以高規格軟硬解決而失敗的題目。流行的方式是將問題分解, 個別強化, 捨棄不需要的部份, 組合成因應需求的系統。例如, 連線數量(MINA), 訊息處理(Camel), 計算能力(Hadoop), 資料存取(Cassandra), 內容管理(Jackrabbit), … 全部都可以分解, 組合, 不需要一個全能的應用伺服器(Application Server)。

更重要的是, 個別專案都經過不斷使用的驗證, 也持續被使用。例如: A 賣場, F 聯誼社, G 廣告商參與的 Hadoop, Cassandra, … 要集中資源或指定聚落開發類似的功能, 都難以負荷。但從滿足大眾市場, 回頭灌溉成的專案, 就能因此受惠。

所以集眾開發必須加上, 個別經營大眾的觀點:

在以上前題成立的狀況, 個別開發也成為可能:

回頭看過去執行專案使用新技術, 會不斷被勸阻, 因為總是增加風險。但最後化險為夷, 是這些新技術總是進展到一個難以預估的地步, 不論是功能或穩定方面, 這些都不是古早開源專案可以想像的。唔, 大約十年前。最後的結果 … 除了組員肯定, 也被客戶讚許(多次廠商競賽, 都協助客戶拔得頭籌) :-)

那些都是隨波逐流的好處, 卻也可能遇到 … 使用協力的專案被腰斬, 功能不如預期, 整合障礙, …。竊認為是技術問題, 調和正正負負的項次, 就不在這裡細細討論。

最後記下一個開放問題: Scrum 方法用在何種開發情境(集中, 聚眾, 集眾)合宜?