推 MOONRAKER: Great 09/14 10:36
推 y2468101216: 推 09/14 10:41
姑且…其實這概念上有很多從laravel「借」來的東西。
因為做為一個區塊的內容，所以我使用了「小工具」的英文名稱「widget」
其中像是Member::all()這種東西我就不提了。
基本上我覺得用controller去取得model傳回來的東西再放進view……
然後其實通常一個頁面可能要處理很多很多個「區塊」。
遇到不同的頁面又要載入同樣一次的區塊，可能又要走model→再進view。
嫌麻煩可能有人就把view寫進一個model裡面，然後load model同時取得view~~~~~~
或是……採用了別人寫好的layout的外掛來設計整個頁面再獨立處理資料~~~~~~
亦或是前些年有人寫的HMVC架構也許到現在還在用之類的……
總之很多很多不同的做法。
可是我一直在想，有沒有能夠讓我們更專注在設計「小工具」、「區塊」這件事情上。
而且僅可能不要複雜的讓這樣的東西只能一次處理一個model對應一個view。
當然……用model處理是個辦法，或許還有很多每個人自己獨特的方式。
在這其中我在僅可能不要改動到ci核心的原則下，自行設計了一個BaseCore的外掛。
(其實是我還不知道要怎麼為這些東西命名)
而這個東西當中目前實作出來的當然上面講的Member::all()這種常用的東西我就
不去再討論他。
主要要講的是我寫的BaseWidget和View(都包含在我的BaseCore的內容)
這個設計的原則，一個widget只能對應一個view(但我還是思考有沒有必要一個widget
，同時具備設計前後台的原則中……)
其用法像這樣：
class MyWidget extends BaseWidget{
protected $view = '資料夾/view檔案';
function __construct(){
parent::__construct();
}
function index(){
return [];
}
//這是考慮如果包含要處理的後台時實作的地方，對此功能我目前無定案。
function backend(){
return [];
}
}
主要的特色在於那個index，他其實就是用來處理你要呈現的資料內容。
最終你return的陣列的內容將會反應在你的$view屬性所表示的view檔案。
(這當中的格式就和原本的ci並無二致了。)
至於這東西是在什麼地方呼叫使用？
我將他設計在是view的階段。
也就是在一個統合的layout中你可以隨時叫用這個widget，其用法如下：
<?=View::widget('widget資料夾/widget檔名')?>
這邊要注意的是，widget檔名的格式要求是xxxxWidget
但是你在使用時，Widget必須被省略………
(就跟Helper的檔名設計是類似的道理。)
再來就是那個Widget的index其實有個…類似laravel提到的DI設計。
也就是說，你寫在libraries、models、或是widget的class
都將可以使用如下的方式載入：
舉例你在libraries寫了一個MyDemo的class，他將可以被如此注入其中：
function index(MyDemo $mydemo){
$mydemo->method();
}
同樣的，widget本身也接受複數的參數例如：
<?=View::widget('xxxx/xxxxWidget','Hello','你好喔')?>
實作時：
function index(MyDemo $mydemo,$param1,$param2){
return [
'mydemo' => $mydemo->method(),
'param1' => $param1,
'param2' => $param2
];
}
可以看到，實作的第一個是被注入的class，所以他不會去接你傳入的參數。
而$param1和$param2才會分別接到'Hello'和'你好喔'的值。
同樣參考過來laravel的設計的是，注入的類別可以在方法的parameters的任意位置。
重點當然是………
只有被注入的類別才會被實作這一點。
(過去常常為了想省掉程式碼而在建構式下寫了一堆載入model浪費了用不到的，
然後又很懶的在需要model時才寫入function，亦或有時要使用搞不好還忘了載入。
不管是model或是class忘記載入都要重寫進來有點小麻煩)
這一個外掛工具我還在開發測試以及發想的階段。
不知道大家對這樣有什麼樣的想法或是建議。
以我自己實際用起來感覺方便很多。
我可以專注在設計一個一個的功能。
不過目前效能方面我還在做測試評估。
至於問我為啥不直接去用laravel就好~~~~~~
我該說……laravel有他的好跟缺點，ci同樣也是如此。
所以我一直在思考有沒有可能合併他們雙方的優點，來改善缺點的問題。
同時因為也看了很多app的編寫模式像是ios的object-c或是swift……
我覺得能夠專注的寫好每一個區域功能比把太多東西廣泛分部在一個控制流程來說
會顯的容易維護許多。
喔對了。寫這個widget還有基於一項很重要的理由就是……
他是可以被測試的。
不過……仍然還是在開發和修正階段的東西。只是可以拿來方便我現在的專案設計。
有什麼意見或建議都歡迎提出。(或是其實有別人已經寫好的範本可以參考的話)
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 123.204.74.73
※ 文章網址: https://www.ptt.cc/bbs/PHP/M.1442075054.A.38D.html
※ 編輯: tkdmaf (123.204.74.73), 09/13/2015 00:30:30
※ 編輯: tkdmaf (123.204.74.73), 09/13/2015 00:31:23