統一架構討論區

[asika32764]

SMS 統一開發架構工作區

隨著大家已經熟悉 Windwalker, composer, ezset 聚合的開發架構，我們需要找一個模式來統一這些套件的安裝與擺放。這個工作區用來討論這些架構並且將實作的程式碼放在此處。

目前面臨的問題

沒有統一的我們自己的 Composer 位置

Windwalker 與 JConsole 為了製作成 Sandbox 所以不能直接更新，元件內的 composer 又無法跟 plugin 外部共用，我們需要一個針對每個專案的統一 composer（或者 composer 支援 merge 額外 json 檔案又更好了），否則每次我們要裝 3rd library 都要全部 commit，檔案數量太重了。希望有一個接近根目錄的 composer 可以讓我們方便做更新

Joomla 3.4 的 composer.json 已經確定放在根目錄，vendor 確定放在 libraries/vendor，我們可以討論一下我們自己的 composer 要怎麼擺放。

Plugin 與 Listener 的位置無法統一

目前我們依賴於 CMF 的 dev plugin 還有 Ezset，大家各自寫有點混亂，而且許多功能如果要寫成外掛又需要刷 schema，有點麻煩。

考慮依照上次的討論結果，將 Ezset 改成巢狀 Listener 的形式。未來會有點像 Bundle 一樣只要塞額外的檔案進去就可以無限擴充 Listener 數量
，不必額外花力氣寫成安裝外掛。

(例如這次的Config抽離工作，其實就很適合寫成套件裝在不同網站上，目前的寫法有些分散)

統一驗證身分

已討論過，參見 Trello
https://trello.com/c/lGOX04f2/32-9

整合開發工具

目前有 PHPStorm 設定檔、CodeSniffer、less compiler、Gulp、JConsole 各種開發工具，未來還要加入 UnitTest

需要避免開發人員啟動專案的負擔太重。

其他各類細項

API 文件要怎麼寫？放哪裡？何時 generate 成 HTML? 各種細部問題歡迎補充

暫定的解決方案

我希望除了 Windwalker 與 JConsole 以外，還要再加一層是我們自己 SMS 的中間層，因為前兩者是公開套件，不會為了我們自己的流程優化，而 SMS 的中介套件可以根據我們自己的流程製作各種接口，至於如何實作就事我們要討論的了。

其他的討論方式

HackPad 最近挺紅的，但我沒什麼用過，用這討論事情會比較方便嘛？

Reference

• Gulp SMS
• SMS Develop Command Tool
• Development-Tools
• SMSTW_PHP_CodeSniffer
• sms-coding-standard

[asika32764]

我們可以先從這篇開始討論，每個議題可以另開issue，有推薦的套件或工具就貼網址上來

@LeoOnTheEarth @michael520

[michael520]

API 文件產生工具我看到這兩個工具，
http://apigen.org/
http://www.phpdoc.org/
這兩個看是否合用，但不知為何我腦子裡一直浮現的是 Sphinx ...

[asika32764]

是指 RESTful API

2014-09-06 8:55 GMT+08:00 Michael Chen [email protected]:

API 文件產生工具我看到這兩個工具，
http://apigen.org/
http://www.phpdoc.org/
這兩個看是否合用，但不知為何我腦子裡一直浮現的是 Sphinx ...

—
Reply to this email directly or view it on GitHub
#1 (comment).

Best Regard

Simon Asika | Kwang Po Tung | 董冠伯

• Founder: Asikart Extension http://ext.asikart.com/
• CTO: SMS Taiwan http://www.bm-sms.com.tw/
• Mobile: 886-928-565-747
• Github: https://github.com/asika32764

[LeoOnTheEarth]

Symfony Console 如果要弄成像 @asika32764 想要的階層式設計的話
可以直接設計一個 Application class 來處理階層式的邏輯處理

可以從這個簡單的範例去拓展
http://symfony.com/doc/current/components/console/single_command_tool.html

看起來如果規則定得清楚的話，console 前期的初始化可以變得很輕鬆，不需要一次把所有的 Command 加進 Application 內

[asika32764]

這只是 Single command 範例而已啊， JConsole 也是用 Application 自動載入 commands

主要是一個 command 能不能附屬於另一個 command，並且被帶著走，Symfony 要做到這樣需要從 Application 特別設計，不算是所有套件都共用的。當然我相信要幹是幹得出來啦

[asika32764]

如果要用 Symfony 做就是要在 Application 寫一個 command 用的 routing

[asika32764]

這是 Symfony 的概念

$ console group:command arg1 arg2 arg3 --option1 --option2

command 只有一層，用 : 最多區分出一至兩層 group

這是 JConsole 的概念

$ console command1 command2 command3... arg1 arg2 -opt1 -opt2 -opt3 --help

The command calling flow is:

rootCommand (console application)
    ->configure
    ->execute

    command1
        ->configure
        ->execute

        commend2
            ->configure
            ->execute

            commend3
                ->configure
                ->execute

            return exitCode

        return exitCode

    return exitCode

return exitCode

理論上可以一直傳遞下去，算是分散式概念，Application 本身不處理 routing

如果我們打的 commands 超過 Command Class 的層次，則多的變成 arguments

[LeoOnTheEarth]

JConsole 的話 command1 command2 command3 全都會被執行?

[asika32764]

command1 如果有 match command2 就會 pass 到下層執行，直到 match 不到 child 為止才會進入 doExecute()

但是 command1 的 configure() 還是會跑一遍，所以我們在 command1::configure() 內設定 Global options 與各類常數，都可以 pass 到所有 children

[asika32764]

喔還有，commandY 與 commandX 如果分屬在不同的樹下面，commandY 可以直接呼叫 commandX 執行任務，類似 HMVC 的模式

我們就很容易做到 install 時先 update，然後繼續 install 之類的流程控制

[LeoOnTheEarth]

在一般的 command 工具裡面，argument 通常都是帶入變數為居多
要在 command 裡面再執行 command 感覺是不太直覺
或是通常會把要再多執行的 command 用變數帶進去執行會比較符合目前常見的用法
像是 ssh tunnel 之類的指令

ssh root@localhost 'echo 123456'

[LeoOnTheEarth]

如果採用物件的繼承方式來寫不是比較直覺嗎XD?

[asika32764]

也不見得，例如

$ git subtree split -P src master staging

git subtree split 都是 commands，後面的 master 與 staging 就是 args 了

[asika32764]

如果採用物件的繼承方式來寫不是比較直覺嗎XD?

意義不一樣喔，你得試過才知道，這跟繼承的概念不太相同，而且用繼承的話，階層是死的，無法在 runtime 整支改變到另一顆樹下面

[asika32764]

是說這種寫法當然不討喜，很難懂阿。Single Action Controller 在 Joomla 社群的評價也是很兩極化

不過看到我們的 controller 可以寫到快千行就知道這種設計有其目的在，主要還是要解決什麼問題這件事情。Nested commands 的目的就是要處理節點遷移跟類似 single action 的模式來讓單一 class 責任降低

缺點是你會有高速增長的 classes 海 XD

[LeoOnTheEarth]

如果中間一個 Node 寫錯，是不是會影響到底下所有的 Node?

[asika32764]

看寫錯什麼？ 理論上會

[LeoOnTheEarth]

另外一個考量是 Debug 的難易度，如果階層太多的話...

[asika32764]

Debug 部分可以研究看看，我的確有碰到階層太多很難 Debug 的狀況，不過這種情形不需要到 Nested 設計就會發生了。只要是兩個 class 共用的 class 出問題，後面用的那個都超難 Debug ~~~~

[LeoOnTheEarth]

看寫錯什麼？

最愚蠢的應該就是名字打錯吧，或是設定出問題，跑了不該跑的程式區塊

[asika32764]

這跟 nested 沒關係喔XD 到處都有喔～～～

[LeoOnTheEarth]

如果只影響一個指令我覺得還好，至少不會感染到其他的指令

[asika32764]

應該說，看寫錯的程度，option 之類的寫錯，可能就整顆樹無法用這個 option

command name 打錯，當然就整支樹不能 access

不過這跟一般 controller 打錯所有 actions 都不能用，或 constructor 設定錯，所有 methods 都被影響是一樣的概念

[asika32764]

最起碼因為名字錯誤的狀況我 Jconsole 寫到現在沒有發生過，因為這實在太大了，大到會立即發現

[asika32764]

阿應該這樣說，每個 command 的 name 是存在自己身上的

假設我 command name 應該叫 import 打成 inport

則自動註冊器會把 inport 註冊上去，結果是你打 inport 可以正常執行指令，help 也會把 inport 列出來一切都會正常執行（當然 unittest 會哀哀叫）

每個 command 是一個 self complete 的執行整體，除非你讓 某個 node 直接 fatal，不然名字打錯其實可以正常執行

[LeoOnTheEarth]

Git 指令的範例
我是覺得他還是把每個指令單獨處理才是
subtree 的部分我沒看到有那些分隔的指令
但像是 git-remote git-init git-push 等等
我想這些在設計與開發的時候應該都是分隔開來開發的

而階層式的指令打法其實就只是 command line 的 UI 設計
就 git 來講就是將一些主程式集做資料夾分類
參考這個 http://git-scm.com/docs
但我覺得不會是 UI 設計去影響到程式的設計才是
能個將各個指令分開來開發我覺得會是比較穩的開發方式
至少會死也只死一支，而且範圍可以很容易被限定住

[asika32764]

當然我想 git 不是以 nested 形式設計的，nested 的所有功能你在 application 用 switch 或 routing 都做的到

我的意思是

在一般的 command 工具裡面，argument 通常都是帶入變數為居多
要在 command 裡面再執行 command 感覺是不太直覺
或是通常會把要再多執行的 command 用變數帶進去執行會比較符合目前常見的用法

這裡會看到 command 下面還是會有多層 command 的

至於為了 UI 影響到程式設計很常見阿，MVC與MVP當年就是為了view driven 所出現的設計

而指死一支這件事情我覺得要定義範圍，寫程式是隨時可以讓整支 fatal error 掉的，要看在什麼程度下的死一支還是死整支

[asika32764]

喔對了，要分開來是可以的喔，每支 commands 不要註冊到另一支 command 下，全部往 application 註冊過去，名字再用 : 分隔群組，就完全是傳統模式喔

[asika32764]

另外「各個指令分開來開發比較穩」這件事情，也是要看做到什麼程度，總不可能一個指令一個 application 吧？

但只要共用 application，就一定會出現 application 掛掉所有 command 都掛的狀況，或是 Timezone 設錯就感染所有 controllers 的狀況，這類的考量與是不是階層式沒什麼關係，個人認為是所有軟體都要面對的課題

[LeoOnTheEarth]

假設的確不是 Command 本身出問題，而問題是出在 Command 之外的部分
我覺得這樣至少你知道不是 Command 本身的邏輯出問題，可以先不顧慮 Command 那裡寫錯了
但若是你需要去顧慮到上層的 Command 是否也出問題的話，這感覺就怪怪的
明明我是在找這個 Command 的問題啊...為什麼問題跑到樓上去了，或是其實會忘了樓上可能出問題

會出問題的確各種可能都會發生
但是否能在出錯的時候直覺地縮小問題的範圍我覺得是可以去考量看看的
或是我們可以把開發者訓練到上下左右都能思考周詳

另外如果你說要用 ':' 當成分隔符號的話那不就跟 Symfony 一樣了嗎XD?
我是在想指令的階層設計 (或者可以說是 Mapping) 可能交給一個單位來負責 (ex: Application)
指令本身專注在完成他應該完成的任務即可，不需要去負責他上下層的指令應該是誰

[asika32764]

假設的確不是 Command 本身出問題，而問題是出在 Command 之外的部分
我覺得這樣至少你知道不是 Command 本身的邏輯出問題，可以先不顧慮 Command 那裡寫錯了
但若是你需要去顧慮到上層的 Command 是否也出問題的話，這感覺就怪怪的
明明我是在找這個 Command 的問題啊...為什麼問題跑到樓上去了，或是其實會忘了樓上可能出問題

基本上，你可以想像 command 是 controller，則進到 model 與 view 以後常常問題都根本出在 input 以上的層次

我是覺得這種狀況很常見

另外如果你說要用 ':' 當成分隔符號的話那不就跟 Symfony 一樣了嗎XD?

意思是工具在那，怎麼用都是使用者的創意

我是在想指令的階層設計 (或者可以說是 Mapping) 可能交給一個單位來負責 (ex: Application)
指令本身專注在完成他應該完成的任務即可，不需要去負責他上下層的指令應該是誰

Nested 本身就是反這個原則的設計囉，這就是他的天性。簡單來說就是因為由中心指派者做分派沒辦法做到輕易遷移節點的工作（當然願意做都做的到）。例如 Symfony 的 Routing 就是由中心 router 來做 nested bundle routing 的設計，但你會花不少時間在配置 routing。或者說他們在用不同的概念做相同的事情，用 routing 模式也可以做到類似的工作阿，但是我還沒看過有人用 routing 在寫 command 就是了。

而 HMVC 其實就是由上層 controller 呼叫另一個 controller 當做他的下層。也不會有需要上下負責的問題，因為大家的確都只做好自己的事情。command 如果有下層，則他的任務就是轉下去而已，不會有其他的任務了。

[asika32764]

Nested 本身就是反這個原則的設計囉，這就是他的天性。

但補充，你還是隨時可以放棄 Nested，反正就是 command + application，可以任意組合，也可以用 routing 模式去抓想要的 command，就連 command 本體都可以當做 application 獨立執行