THE MOMENT, THE MEMENTO

2009年08月24日

干扰Zend_Layout的resources.view.encoding

标签:, , — 吴德文 @ 13:07

前情提要:最近开始好好的学习Zend Framework(zf)。其实以前也学了一阵子zf(再之前学的就是FleaPHP了),那还是1.5版本的时候,可惜忙着其它事情,就没有学下去,一个项目也就扔了一个半成品在那里。暑假开始做一个单位的项目,就重新把zf捡了起来,当然现在用的是1.8.4了(虽然zf版本已经到了1.9.1,可是zend-ce用的还是1.8.4,它什么时候才更新呢?)。

项目是还一边学着一边做的,同时看着的有快速入门(也是Zend Studio上的example项目),参考手册入门教程(从1.5.2到1.6.3),以及www.phpchina.com上多模块应用程序的相关文章(如:用Zend_Application实现多模块(modules)及多模板(templates)应用程序)。本来是希望多学些东西,然后直接写出理想的程序雏形,可惜这些从简单到复杂的教程内容混杂在一起,自己的代码也就不在纯洁了,开始互相干扰了。

经过几天的努力建立了简单的MVC雏形,主要是写了一个统一通用的EntityManager(我的目标是能像Java的EJB 3.0一样管理Entity,只是不明白Zend为什么没有提供这样的结构)花了比较长的时间。

Layout是参考着入门教程来写的,当写完Bootstrap的_initViewHelpers()时,我想为什么不把view的一些设定放在application.ini中去呢?于是便参考了phpchina.com上面的文章设置了resources.view.*的内容,其中包括resources.view.encoding=”UTF-8″。

这样问题就来了。

开始往layout.phtml中写入$this->baseUrl()时,发现系统不能正常显示:

Fatal error: Uncaught exception ‘Zend_Loader_PluginLoader_Exception’ with message ‘Plugin by name ‘BaseUrl’ was not found in the registry; used paths: Zend_View_Helper_: Zend/View/Helper/:./views/helpers/’

虽然路径是对的但是就是找不到BaseUrl助手;与此同时,在Controller中设定的title变量也不显示。然后,这两个内容在views/scripts/index.phtml中是可以正常显示的。

开始以为是入门教程有问题,认为可能是Layout和View的调用顺序不一样,有些东西在layout中没有初始化。于是到处查Layout和View的差别,甚至试图在layout和view script中分别把$this变量打印出来比较差别,最终还是徒劳,还在想是不是该好好将参考手册乃至于API精读一下。

今天下午,不知怎的,突然开窍了。心想,既然人家的入门教程写了这么多人看都没有问题,那么上面的东西应该是对的,为什么不放弃自己项目中杂七杂八的想法,老老实实的遵循教程中简单的思路试试看行不行呢?

于是重新新建一个项目,遵照入门教程的步骤一步步进行(当然由于是测试layout,数据库以及Model就没有建立了),发现这样就不存在之前的问题。这说明问题是我自己项目中混乱的代码引起的,就开始排查。

最后,发现问题就出在resources.view.encoding=”UTF-8″这句话上面,即便是我将值改成默认的ISO-8859-1,错误依旧。解决办法就是将这句话去掉。

至于为什么这句话会引起这么大的问题,暂时先不管了,以后深入使用View的时候应该就会了解了吧。

思考:

这次错误虽然只是短短的一句话,但是却让项目陷入了停顿状态,让我近一个礼拜都心神不宁。写下这篇文章目的一个是让其它人遇到相同问题的时候,能搜到解决方案;此外,也在此审视一下自己的一些态度方法。

首先,是自己贪快、贪多。一开始就没有好好遵照某一个教程完成一个项目,很多方法只是看了文章还没有实践,就想着开始改进它。教程看到一半,就想依照心中实际项目的需要,又从其它教程中拉入自己还不是很熟悉的内容进来,最终让代码失去了控制。就好像,一种内功连到一半还不熟练,就想把另一种不熟练的内功融合进来,这样轻则神志大乱,重则吐血而亡。这个似乎是我性格中的毛病,在很多方面都有类似的例子,以后一定要切记、切记呀。

其次,当发生错误的时候,始终在自己的思路中钻牛角尖。老是想在一团混乱中找到一丝线索,乃至于把简单的事情复杂化,要去追寻事物的原理。事实上,这样一个简单的东西,人家教程里的东西就已经是一种经验(模式),不会错的,就是大家该遵循的。如果我及早放弃自己的思路,老老实实按照人家经验的做法,问题就能提早解决。其实我也经常说别人不肯放弃自己的思路而遵循别人的思路去解决问题,只是没想到自己也犯了这样的毛病,以后切记、切记呀。


Related:

2008年02月20日

FTP传送扩展名为ASP的数据库要注意传输类型

标签:, , , — 吴德文 @ 17:10

去年开始接管一个单位的网站,是用ASP制作的,其数据库为了防止别人下载命名成了abc.asp的形式。

管理网站首要的任务就是备份、恢复了,尤其是数据库。通常都是用FTP下载下来, 在本地进行备份。

FTP一直都用图形化工具FileZilla,文件的传输类型(文本或者是二进制)默认都已经设定好了,所以也就基本上都忘记这回事了。

刚接管这个ASP网站的时候,用FTP下载下数据库,然后再传到一个新建的网站上做修改测试。可新网站提示说数据库格式无法识别。开始我还想是不是下载下来的数据库被我的Access 2003打开修改以后被保存成2003格式,所以机器上的旧ASP程序认不出来。此后,就一直小小心心不敢在本地直接修改数据库,只能通过管理界面提供的接口。有一次为了删除所有的垃圾留言,还特地修改asp源代码把删除一条的按钮改成删除全部。

过了一个年以后,就把这个约束给忘了。这次在无法登录的情况下想要修改数据库复制一个管理员出来,最后在回传数据库文件的时候又出问题了。理所当然的,我又以为是数据库格式问题。可是后来的发现证明的我想法是错的。一个发现是Access(不论是2003或者是2007)在打开数据库的时候会显示此数据库是什么格式,是2000或者2003,即便修改过以后,格式不会改变;另一个发现是我将未修改过的数据库回传会网站的时候也遇到这个问题。这就说明不是Access格式的问题了,而纯粹是FTP传输过程中改变文件内容了。当想到FTP传输过程的问题是,我突然想到自己传的是一个ASP文件,而FTP工具肯定将其作为文本文来传输了,文件内容自然就被改变了。

想到这点,赶紧在设置里将文本类型的ASP扩展名删除,再进行回传。这下就没有问题了。嗯,这下终于松了口气 ,以后可以随便修改数据库文件了。只是不知道以后再过多久我会不会又忘记这个设置的问题,而且那个时候会不会记得来看这篇文章。但愿是不要忘记的好。


Related:

2007年11月6日

Exception of PHP Memory Limit

标签:, , — 吴德文 @ 16:23

想给Wordpress添加上Tag的功能,于是找到Simple Tags的插件。安装不成功,阅读了readme后,发现1.1.1版本的Simple Tags需要Wordpress 2.3的支持。

于是乎,只好下载了新版的Wordpress,进行升级安装。将新版文件替换好以后,执行Upgrade.php一直不成功,不解。开始一直以为升级中途中断造成数据库不一致。后来在终端下执行php upgrade.php,得到错误Allowed memory size of 8388608 bytes exhausted

Google,阅读了中国IT技术论坛的一篇文章后得知原来是PHP对script使用内存的限制,默认是设定为8MB,而如果script要求使用超过8MB的内存,就会发生错误。解决这个问题的办法就是加大或者这个内存使用限制就可以了。

加大 8MB 記憶體使用限制,有兩個方法擇其一即可:
在最上層的 PHP script,加入一行
ini_set(”memory_limit”,”12M”);
修改 php.ini 裡的 memory_limit 的設置值 8M 改為 12M
memory_limit = 12M

如果擴大到 12M 仍然相同的錯誤發生,則再加大 12M 限制。但是請注意,應該還是要去寫出好的程式;而不是加大記憶體限制,不管coding 好不好。

三,最后,经过咨询杨波兄弟,修改wp服务器根目录下wp-config.php文件。

办法是:在该文件中第一行加入:ini_set(”memory_limit”, “-1″);

于是我在wp-config.php的所有设置前面添加了ini_set('memory_limit', '12M');之后就好了,升级顺利完成。


Related:

莫名的电脑故障

标签:, , — 吴德文 @ 12:17

自从9月初出差回来以后,电脑就总是频繁出现同样的故障——目前暂时怀疑为硬盘故障。
(全文…)


Related:

Valid XHTML 1.1 Valid CSS! Creative Commons License WordPress 所驱动