PHP widget的自我感悟

             转眼抛弃smarty已经有一段时间了,慢慢的习惯性使用上来widget,经过这段时间的合并性整理,越发的觉得以前中搜微件技术其实是个很简单的玩意.

            也行很多初中级程序员还侵泡在使用框架的自娱自乐中,就如前几天群里一个群友说的,今天面试了一个3-4年YII工作经验的人,问了2个问题：说YII的路由分发是在那个类处理的,问他yii里面application和module有什么区别,都是一问三不知.发现原来大部分程序员一直处于把框架当语言或者工具在使用,而没有自己的定义和理解.

            琢磨着大家也许还是习惯的用于我先定义一个layout   然后写一个veiw文件   然后分作几个widgets去填充,实际上你是在用widgets,但是你的这种wedgets是否只有头尾共用了?widget这么用的优势?慢慢的你会去想办法去公,去全局.你会觉得这种逐个文件的跟踪会很麻烦,会去尝试改变

            1,widget的自我改变方案

            去年的时候无意间,看到一个同事把widgets看成一个action,这是一个很不错的设计,应该是说很有创意的设计,从引用到取值渲染都是很不错的,尤其是项目内的引入那更是十分合适.还是以实际代码来展示吧,首先我们查看一下问题目录

大家可以清楚的看到,我的文件都在views里面,先进入offercontroller.php

在这里面我进行的数据的封装和逻辑处理等,而不是简单的调用一个wedgets然后再放入下层出来,通过render 和renderPartial进行不同的渲染页面,那么我们马上进入products.php里面看看我们如何加载actionlist方法, 通过一个很简单的方法就加载了一个小模块页面,那么我们继续进入list页面中,

大家明显发现这里面貌似和widgets如出一辙,也许这本就是一样的,只是简化了几步widgets而已,这就完美的解决了查找问题时候代码层数过多,定位牵涉过广的问题,同时本人最讨厌文件数过多,还有参数的无限传递,没有任何缘由只是本能的反感而已,所以大家可以看到我的views文件内部都是$this进行获取值,因为我将变量都进行public 就不会出现传值的各种问题,也许这在单个module下面用起来的十分敏捷,直观式的,但是慢慢的系统总要进行一体化,我们要做到模型化所有部件放入都能如微件般,这是我们马上想到我的方法是可以全站调用的,那么问题在哪里呢？参数!我们忽略了它,在其它module中我们直接使用,我们还如何$this->xxx这般简便的拿到数据,为此我和我们主管商讨了一下,我当时头脑一热想到一种有趣的方案,将整个项目的参数全部public放入基层类中,那么我们就可以肆无忌惮的使用了...但是我们同时给出不行的答案,为什么不行我也不明白,只是都感觉哪里不对,所以就卡在这里了!但是项目还是要一体化,马上我们步入正轨

2,widgets正规话,

    前面已经提到很多这方面知识,我自认我的书面表达能力很差劲,能看到这里表明你对widgets已经超出的菜鸟级别,这种常规化和平时大家用的大同小异,文件目录是一样的,唯一我们只是做了一个统筹规划,如

  

我们可以对页面进行分块,然后每一块组装,通过无数的文件,2,3次的深入最终实现了一个页面,当我们和前端样式(每个widget带自己的样式)很好的统一处理后,这里面每一个widgets 如:pri_left_toll都能在全站进行随意调用,我们更可以将$tree存入数据库中,这样用一个标识进行判断是否显示,那么我们就可以在后台玩拼图般实现了前台的页面.

说到这里是否已经可以说完成了,但是本人有点洁癖,我十分的讨厌过多的文件和排查的一层层深入,和烟花缭乱的参数传递!那么我们又回到的第一步的最后一步续,这时候我们就可以联想到前面提到过的微件.这里我不得不抱怨一下微件->一个拥有很好设计理念的半残废,不过在过去的痛苦中我还是发现了他的价值->数据源,这就是我们前面卡住点的钥匙,假如我们将所有的数据通过数据源进行传递,那么我们就解决了数据调用的问题,假如我们再加入其它变量进行控制我们是否可以做到列表一体化,假如前端能把每一块view进行处理,我们是不是简便的实现了通用性,那么我们将不需要存$tree,我们只需要存一个数据源也就是我们常说的接口,至于如何能在前端进行随意拖动那些,这就需要JS前端高手来为大家做详细的介绍了,希望各位大神的指点!