姑且…其实这概念上有很多从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还有基于一项很重要的理由就是……
他是可以被测试的。
不过……仍然还是在开发和修正阶段的东西。只是可以拿来方便我现在的专案设计。
有什么意见或建议都欢迎提出。(或是其实有别人已经写好的范本可以参考的话)