thinkphp的RBAC实现一直没弄明白怎么做。感觉很复杂。其实自己也可以diy一套自己的RBAC吧，也许更容易理解和使用。

  以下是我的一些想法。

  1.权限数据的存储

  我的选择：独立配置一个access.php文件。

  理由：通常RBAC数据都是存在数据库中的。不过有这个必要吗？存在数据库，使用的时候还是要缓存出来提高使用效率，那为什么不直接存在配置文件中呢？特别是thinkphp1.6RC1配置扩展的功能，大大方便了调用。

   2.何处检测权限

  我的选择：设置一个基类BaseAction，在它初始化方法中检测权限。

  理由：合理利用基类，可以大大减少代码，这个本来就是必须的利用的。那么可以顺便就在初始化的时候实现这个功能。

  3.如何检测权限

  我的选择：通过MODULE_NAME和ACTION_NAME两个变量，在access.php中查询权限

  理由：MODULE_NAME和ACTION_NAME是App对象运行中得到的两个变量，因此整个环境中都能得到这两个值。其中MODULE_NAME值为调用的Action的名字（例如,名为IndexAction，则MODULE_NAME为Index，ACTION_NAME类似），ACTION_NAME值为调用的方法名。称。那么，通过合理化组织的access.php，可以查询到对应模块对应方法的权限。

  4.access.php的写法（待完善）

  a.键值对的选择

  考虑到对于一个工程，Action的数量也许变动较多，而UserGroup变动相对较少，就更改方便来说，键取Action，值对应相对的UserGroup比较好。

  同时，考虑到调用方便，键我采用的是MODULE_MANE.'_'ACTION_NAME的方式命名。

  例如：

'Index_index'=>'*', 
'Index_login'=>'none',

  (这样呢

'Index'=>array(  'index'=>'*',  
                 'login'=>'none' 
              ) 

这样的好处是，一个Action的放在一个键下面，修改也许方便点。待考虑。）

b.值的命名

  *                      任何人都可以访问

  none                 仅仅未登陆用户可以访问

 notallow:            考虑到UserGroup的扩展性，这个可能是有用的。例如

'Article_read'=>'notallow:none',//禁止匿名用户访问 

 fun:                   调用自定义函数，放在最后。例如

'Article_update'=>'admin,fun:is_writer',//管理员和作者可以修改文章 

   要求：所有验证函数都要接受一个数组变量，返回true或者false返回是否具有权限

   工欲善其事，必先利其器。开发thinkphp用什么ide是一个问题。很多高手喜欢用editplus，因为它启动快速、占用资源小，而且有非常好的自动完成和剪辑库的功能。不过，对于像我等这种菜鸟来说，editplus的功能还是不够强大。比如，连代码提示也没有，实在是不能忍。因此，我选择了phpdesigner这个ide。但是，这个ide(包括试用过的其他很多ide)似乎没有代码自动完成功能（我没有找到），看着网上高手发布的acp文件只有流口水的份。

    能不能两者兼得呢?

    利用Autohotkey的hotstring，其实可以方便地实现自动完成功能。因此，就使用phpdesigner这个软件就可以了

    以下为Autohotkey代码，完善中。。。（如对Autohotkey使用有疑问，可以在网上搜索。有时间我也写写相关的入门文章.)

::ta::$this->assign('',);{left 4}  
::td::$this->display();  
::ab::public class Action extends BaseAction{{}{}}{left 27}  
::an::public class Action extends Action{{}{}}{left 23}  
::fun::public function (){{}{}}{left 4} 
::arr::
	Clipboard=
	(
	array=(
		''=>'',
		''=>'',
		''=>''
			`)
	)
	send,^v
	Return
 

thinkphp即将推出新功能，性能翻倍，操作更简捷

» 阅读该日志全文...

  @定位在 .Tpl

  :定位在 .Tpl/default

 

   thinkphp1.6RC1提供了Widget功能，因此可以组件化开发了，非常棒。最近想对它做点加强，发现走入了误区。

   我想做一个继承于Widget的类，能够按照传递的$data中数据进行处理，因此自定义了一套规则。然后想把类做得更强些，于是规则不断地增多，什么数据库查询语句都往里面丢，但是……这样做不是将这些逻辑都放在Action里面去了吗？毕竟，调用widget的时候，是在Action里面组装$data的。这样做是不好的，违背了封装的原则。

  还是应该老老实实做些专门的Widget，在其中处理Model类的查询等工作。这样也避免将业务逻辑放在Action里面所带来的弊端。