Showing posts with label CMS. Show all posts
Showing posts with label CMS. Show all posts

2012/12/09

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 表單

11 New XML Form

b. 建立表單項目

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

12 Construct Form

建妥表單, 再到下一步。

c. 輸出 PDF 表單

13 Export PDF

d. PDF 表單選項

14 Export PDF Options

e. PDF 表單檔名

15 Export PDF Filename

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

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

2. 取出資料

a. 填寫表單資料

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

21 Fill PDF

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

b. 讀取表單資料

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

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

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

22 Use pdftk

和先前 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) …

31 Preview PDF Note

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

2010/11/08

應用系統的版本管理

一段歷史

經過幾年軟體版本管理工具爆炸性的競合, 如果不考慮控制的問題, 我們可以自由選用 subversion(svn), mercurial(hg) 以及 git。svn 存在時間最早, 在有一些歷史的專案和中小公司比較常見; hg 由於簡單明確, 大型源碼社群如 sourceforge, codeplex, google code 普遍接受; 而 git 強大穩定, 則是技客首選。

這三者陸續在用, 雖然深淺各有不同, 從歷史角度來看: 最早通用的 cvs 是管理檔案版本, 所以會有 v1.0, v1.1, v1.2, ….。svn 側重整個專案版本, 標示版本以整個儲存庫為準 r123, r223, r323, … (r=revision)。大概是 cvs 時期一個檔案就可做完一件事, 到了 svn 得靠一堆檔案 … 請參考『軟體工程師的進化』一文。

到了 dvcs(hg, git) 回歸功能面管理, 版本像是 229a46966a72, 13a7d2806d50, 64d88c389b67, … 的 uuid。意義不再是檔案版本編號(v1.0), 或由儲存庫變更序號(r123)做認定。應該沒有人可從 dvcs 裡版本號碼看出任何意義。一方面在每次提交版本(commit)輔以適當註解, 而整體來看, 端視儲存庫擁有者認定版本的意義。因為是 dvcs … 只要有心, 人人都可以是儲存庫擁有者 … peace!

對一個專案來說, 針對檔案變更追蹤是過小, 像流行的 MVC (Model-View-Controller)在概念上就跨了三層。若針對儲存庫變更追蹤又太大, 變更頻繁的話, revision 就如同雪片般, 好看是好看, 但一般也只是好看。因此, dvcs 當是比較符合趨勢的選擇。

一種問題

交待完歷史, 回頭看主題。假設專案有源碼要管理, 這個應用系統是承上啟下, 也就是依據上游源碼為基礎, 提供下游客戶穩定、加強、或客製的版本。是種常見模型:
上游儲存庫 UR - Upstream Repository
我的儲存庫 MR - My Repositroy

源碼儲存庫畢竟是技術人員才會接觸到, 大部分狀況以策略解決: 有時將上游源碼設定為程式庫, 簡化問題; 或以廠商分枝(Vendor Braches)將上游源碼納入專案; 而產品類專案, 可忽略 n 個客戶問題。

但如果使用開放源碼 CMS, CRM 或 ERP 這類應用為主的系統, 上游持續加強版本, 下游因應需求不斷變更 … 會爆炸的點大概就是位居中間的儲存庫。
在網路上, 看到相關問題討論有:
  1. 非官方 hg 流程 中 Offsite working on dynamic websites。其中『Upgrading Drupal with Git』(部落格已落幕, 可參考 archive.org 資料)。
  2. 也是 drupal 開發, 教學視訊 Git With Drupal 7
  3. opentaps(ERP) 的建議 Managing Customizations with Upgrades, 大抵是分為四個層次: a. 瞭解現有的, 將異動最小化 b. 貢獻源碼, 免除版本差異, 透過社群改進 c. 獨立應用程式在特定目錄下 d. 若修改核心及社群不接受的源碼, 得注意合併問題。最末項不建議, 因容易出包。
上面第三項 "在特定目錄下" 放應用程式, 是大部分應用系統普遍的做法, 像 SugarCRM 也有類似的機制。

通常專案會設定上游的版本, 但長期提供服務, 必然會面對上游版本變更。而下游的需求, 投入行業時間夠久, 一般也會有共通方式解決, 例如提供一個檔案上傳或流程整合的功能, 應該也不希望一家處理過版本提升後, 還得要處理其他家客戶相同問題。

技術上, 沒有通用做法的話, 能抑制爆炸的源碼就大概只有爆炸的肝。(以爆制爆?)

一項解法

如果著眼於儲存庫, 所有問題都成為一團。首先區分上游變更, 與下游需求這兩個變動的來源。其他像共通功能的開發, 問題的修正, … 先納入下游需求。

再來, 如版本管理的演化(csv → svn → dvcs), 因時制宜般, 上游變更以分枝(branches)處理, 下游需求以變更佇列(patchs queue)對付, 再建立一個儲存庫負責照拂需求的變更佇列, 是為『變更儲存庫』。
變更儲存庫PR - Patch Repository
變更佇列在 git 中有外掛 stgit, quilt, 至於 hg 是內建 mq (mercurial queues)。

在手上實際 ERP 案例中, 上游儲存庫每個月大約有 800kb 左右的差異檔(diff), 而變更佇列除了中文化有 5mb 的差異檔, 其他加起來不到 300kb。每月同步上游儲存庫後, 再更新變更佇列, 也就是 UR 與 PR 會有版本對應的關係。只要 UR 與 PR 同步後, 就可一體適用其他相同系統的客戶。節省下的資源可專注差異化部份。

一方面是變更的大小與不同機制的搭配, 另一方面是變更佇列對每項修補差異的處理, 比分枝來得直覺。例如把中文化和其他修補一起放入同一個分枝中, 當上游版本更新, 要合併到分枝時, 假使自動合併無效, 要看到檔案才能處理, 同時可能也要處理 API 差異之類的。簡單來說, 就是要有經驗的工程師才能處理版本合併的事務。如果是以變更佇列處理的規劃, 就很方便分工, 中文化部份安排通中/英文, 細心的工程助理打點即可。

參考