<< 以下為轉載文章。。。>>
Page Extension 中加入客製 Page Action
在 VSCode 上直接利用 AL 語言開發 Business Central 的 Extensions。也可以藉它他的開發環境直接連結 Github 做版本控管
2019/6/9
在上一篇文章中，我們已經把需求 (規格) 的第 1–4 項做掉。也許你覺得非常簡單，不過就是加加欄位；也許你覺得要熟悉這個 Framework 需要時間，例如 Page Action 或是各種 Properties (如上一篇有設定的 Table relation) 的運作方式。在我們繼續客製下去之前，我們要來討論兩個議題。
第一個議題有關於新一代的客製方法論 Extensions。還記得我們的 Business Central 開發原則第一條：”能不客製就不客製” 嗎？ 客製其實是有負擔的，而這個負擔最明顯的會是在我們要將系統升級時。想像我們現在是用 Business Central 2019 Spring 的版本來做客製。原本系統標準的程式碼假設有十萬行好了。這時候，我們東加一行西加一行，或是像前面前篇一樣在既有的 Table 或是 Page 上面加欄位。直到 2020 年秋季，客戶想要升級成最新的 Business Central。但是這時標準的程式碼可能已經跟以前不同、標準的功能變多了、或是總共已經有了十一萬行程式碼了，怎麼辦？這時我們就要做 Code merge。以最新版本的 Business Central 做為基底，然後把我們所做的客製一個一個加上去。
可想而知，當一個系統重度客製時，要這樣將動到標準物件的客製程式碼搬過去然後再做系統測試，非常的麻煩耗時。反而是我們之前新加的 Table 50000, Page 50000 這種新物件，直接搬過去就好了！反正他也沒有所謂的 “新版標準物件” 會跟他衝突。Extensions 就是在這個情況下被提出的解決方案。想要在標準的 Table “G/L Account” 加欄位嗎，沒問題，你就做一個新物件 “Table Extension” 50000 就好了！這個 Table Extension 在定義時我們就定義它擴展 (Extends) 了 Table “G/L Account”。所有要在 “G/L Account” 新加的欄位都放在這個 Table Extension 50000 中，而系統編譯 (Compile) 時會自動將 Table “G/L Account” 和 Table Extension 50000 連結在一起。當然，Page 的概念也是一樣，會有一種 Page Extension 的物件，你可以在裡面放入想呈現的客製欄位，或是新的 Page Action。最棒的是，在升級時，我們只要把這些 Table Extensions, Page Extensions 通通打成一包，掛載到開發環境中就可以了！
第二個議題我們來討論有關於 CSIDE 裡面過多使用 “Properties” 來做開發的方式。即除了程式碼之外，魔鬼常常藏在某個物件、某個欄位的 Properties 中。這種開發模式除了讓程式設計師不好在既有的客製上繼續開發之外，也讓人不好 Debug。筆者一開始接觸 CSIDE 時，非常不習慣要到 C/AL Globals 或是 C/AL Locals 去定義變數。為什麼一定要藏起來呢，不能像 C++ 一樣直接定義 int x = 5; 嗎？以當今程式開發的潮流，程式碼的呈現要易於協作、閱讀，或是放在 Github 做版本控管；而在強大的 Code Editor，如 VSCode 的輔助之下，也使這種文本式的開發模式變得更有效率。如果有接觸過 Web 開發的程式設計師，不妨想像我們放棄以前在 Dreamweaver 上拉一拉讓它產生 HTML 和 CSS，而是現在的直接在 Sublime Text 上(或是任何你喜歡的 Code Editor) 硬幹程式碼。
在下一篇文章中，我們會繼續在 CSIDE 中完成 5~8 項的客製，也將會觸及到 Business Central 最重要的開發觀念：Event-driven, Publishers, Subscribers 的設計模式。
*********************************************************************************
<< 以上文章，經作者 Ray 同意，轉載自 https://medium.com/@nturay0321 >>
留言
張貼留言
留下您的意見