可以在不同阶段定制这些事件，其实说白了，就是重新定义这几个OnXXX函数，用给定形式的参数，你也可以自己加入自己的事件，比如你在定义自己的组件时，在规范文件中定义好该组件可能有的事件函数及参数，以后你在使用该组件时可以直接定义这些被允许的函数——不过我认为这种方式过于复杂，且要大量读入并分析XML文件，虽然十分地严谨，很安全，但有些过分了，也没有充分利用到PHP本身的灵活性，我的思路是用类似于DELPHI的函数句柄赋值的办法或是用C的回调函数的特性，即可在写代码时在任何时间任何地点定义事件，而仍然能明确事件发出者及类型并有足够地安全性保证，且无需机械地强制各个组件只能有哪些事件，代码修改及扩展都十分方便。当然，在做大项目的时候，严格的定义是必要的，不过，即使如此，该框架处理事件的方法还是有些古板。
它的模板我认为是一个比较好的想法，它的模板有些类似于点NET的ASP文件在编译前的文件（我对ASP点NET并不熟，但明白一些原理），但起作用的方式则类似于DELPHI的FORM文件，是一个很好的概念，唯的一缺点是用DW之类所见即所得的通用编辑器则感觉不是很顺手，因为一个模板中可以同时把几个互斥的组件放在一起，而只在运行过程中决定显示哪些。
就我本人看该框架的代码，还是发现它有一些非常弱的项。其中最主要的一个就是路径的问题，可扩展性很低，应该比较适用于专用主机，对一些受限主机（目录限制或是权限限制）就无能为力了，也无相应的提醒措施（也无相关接口）。它对某些资源或文件的路径，用了一种繁琐的叫assetService的机制，目的就是确定文件的路径，作者自己也说，如果用了这个服务，系统消耗会明显增加，其实这个是借鉴了FLASH中asset library的概念，它这样虽然可以任意指定路径，但每次都必须重新校验，有些得不偿失。我的作法则是固定好几个主要路径，而其的子目录都可随意，就综合平衡了两者的矛盾。由于对路径问题缺乏考虑，导致该框架对语言设置、个性化模板等无能为力，如要翻译一个项目，手续之繁，工作量之大是可想而知的，而且极易出错。这是该框架中最严重的一个问题。
从总体上来说，该框架的理念上，设计上，代码上绝对都属一流。当然不足总是有的，不过完全不妨碍我们研究及学习它。它的代码我并未全看，只主要看了几个核心程序及一些说明，但已能足够看清楚其结构与思想，对作者深表佩服，但对其中的不足也深表遗憾。不管怎么样，它都绝对是研究PHP事件驱动代码的好作品。因此强烈推荐！
它的模板我认为是一个比较好的想法，它的模板有些类似于点NET的ASP文件在编译前的文件（我对ASP点NET并不熟，但明白一些原理），但起作用的方式则类似于DELPHI的FORM文件，是一个很好的概念，唯的一缺点是用DW之类所见即所得的通用编辑器则感觉不是很顺手，因为一个模板中可以同时把几个互斥的组件放在一起，而只在运行过程中决定显示哪些。
就我本人看该框架的代码，还是发现它有一些非常弱的项。其中最主要的一个就是路径的问题，可扩展性很低，应该比较适用于专用主机，对一些受限主机（目录限制或是权限限制）就无能为力了，也无相应的提醒措施（也无相关接口）。它对某些资源或文件的路径，用了一种繁琐的叫assetService的机制，目的就是确定文件的路径，作者自己也说，如果用了这个服务，系统消耗会明显增加，其实这个是借鉴了FLASH中asset library的概念，它这样虽然可以任意指定路径，但每次都必须重新校验，有些得不偿失。我的作法则是固定好几个主要路径，而其的子目录都可随意，就综合平衡了两者的矛盾。由于对路径问题缺乏考虑，导致该框架对语言设置、个性化模板等无能为力，如要翻译一个项目，手续之繁，工作量之大是可想而知的，而且极易出错。这是该框架中最严重的一个问题。
从总体上来说，该框架的理念上，设计上，代码上绝对都属一流。当然不足总是有的，不过完全不妨碍我们研究及学习它。它的代码我并未全看，只主要看了几个核心程序及一些说明，但已能足够看清楚其结构与思想，对作者深表佩服，但对其中的不足也深表遗憾。不管怎么样，它都绝对是研究PHP事件驱动代码的好作品。因此强烈推荐！
相关文章
 我来说两句 |
对此文章发表了评论 |
评论列表 （最新 评论仅限网友观点！）
推荐文章
热门文章
