曾经，我很羡慕 Django 等框架那完善的自动化工具。说实话，在 MVC 框架中不停的建立Controller、Action 是一件又枯燥，又麻烦的事情。而且，维护起来也颇费功夫。所以在 ninnypro 中我引入了一个 cli 工具，用于创建 Controller、Action 以及更新 ACL 的资源表。

现在，这些都将成为历史了。

Zend Framework 引入了 Zend_Tool 和 Zend_Application 两个包，用于自动化和快速集成。并且成熟的命令行工具 zf 也可以使用了。例如这里！！

zf 将程序员的关注点聚焦到程序功能和细节的实现，更加的统一和方便。跟 ninnypro 的思路类似，以放弃灵活性为代价，换取约束性和开发速度。

如果我有精力，或许会在此基础上重新建构 ninnypro 吧。

http://devzone.zend.com/article/4045-Zend-Framework-1.7.0-is-now-available

新版本放出，除了修复了近三百个 bug 外，还有下面的新功能。

• Zend_Amf with support for AMF0 and AMF3 protocols
• Dojo Toolkit 1.2.1
• Support for dijit editor available in the Dojo Toolkit
• Zend_Service_Twitter
• ZendX_JQuery in extras library
• Metadata API in Zend_Cache
• Google book search API in Zend_Gdata
• Preliminary support for GData Protocol v2 in Zend_Gdata
• Support for skip data processing in Zend_Search_Lucene
• Support for Open Office XML documents in Zend_Search_Lucene indexer
• Performance enhancements in Zend_Loader, Zend_Controller, and server components
• Zend_Mail_Storage_Writable_Maildir enhancements for mail delivery
• Zend_Tool in incubator
• Zend_Text_Table for formatting table using characters
• Zend_ProgressBar
• Zend_Config_Writer
• ZendX_Console_Unix_Process in the extras library
• Zend_Db_Table_Select support for Zend_Paginator
• Global parameters for routes
• Using Chain-Routes for Hostname-Routes via Zend_Config
• I18N improvements
  • Application wide locale for all classes
  • Data retrieving methods are now static
  • Additional cache handling methods in all I18N classes
  • Zend_Translate API simplified
• File transfer enhancements
  • Support for file elements in subforms
  • Support for multifile elements
  • Support for MAX_FILES_SIZE in form
  • Support for breaking validation chain
  • Support for translation of failure ,messages
  • New IsCompressed, IsImage, ExcludeMimeType, ExcludeExtension validators
  • Support for FileInfo extension in MimeType validator
• Zend_Db_Table_Select adapater for Zend_Paginator
• Support for custom adapters in Zend_Paginator
• More flexible handling of complex types in Zend_Soap

可以看到，由于改进了 Zend_Loader 和 Zend_Controller，性能应该会得到提升。

同时通过 Zend_Config_Writera 修改config文件会变得更加容易。

由于有了 Zend_Paginator ，ninnypro 中的分页的 helper 肯定要修改了。

Zend_Tools 也会给 ninnypro 的辅助工具带来一些变化。

Zend_JQuery 将替代 Ninny_View_Helper_Jquery。

呼，突然发现，这么多要跟进的内容。

首先，这不是一个指南，这只是一个简易说明。描述了如何在 netbeans 6.5 rc for php 中建立、开发、调试 Zend Framework 项目。

step by step:

1. 安装 netbeans 6.5 rc for php，由于 netbeans 6.5 rc for php 官方只放出了英文版本。中文版本要在这里下载。

2. 安装 xdebug，这不是必要的一部，不过如果你想在 netbeans 中调试 php。这是非常必要的。相关内容去 xdebug 官方网站了解，这里也有简单的说明。

3. 我假设你在安装 netbeans 6.5 rc for php 未遇到任何问题，如果遇到了，请参考 netbeans 的 FAQ 关于安装的部分。

4. 打开 netbeans 6.5 rc for php，在菜单中选择“新建项目”。当然更多时候 Ctrl+Shift+N 是一个更好的主意。

5. 选择“PHP 应用程序”点下一步。也可以导入现有的代码，实际上两者并无本质区别。

6. 设置项目的名称以及存储目录。实际上这个存储目录需要将所有项目用到的文件，如代码、文档、配置都包含进去，否则开发时将遇到无穷无尽的从 netbeans 切换到其他工具，再切换回来的情况。而用到的不再进行修改的库文件，反而可以不用包含。

7. 设置好名称和目录后，在“运行配置”中选择项目的部署方式，以及索引文件。通常本地开发网站，默认选择第一种方式即可。这时，netbeans 会默认以项目目录作为 webroot。索引文件可先随意选择一个项目目录中的文件。通常 Zend Framework 开发中 webroot 只是包含 index.php 入口和样式、图片等客户端使用的文件。例如目录“<项目目录>/www”。由于 Zend Framework 部署的特殊性，这里还要做修改。

8. 在“项目”面板中选择刚才建立的 php 项目，点击鼠标右键选择菜单项“属性”。

9. 在类别“源”的“Web 根目录”选择你真正的 webroot。例如：<项目目录>/www。

10. 在“项目属性”的“运行配置”类别中，调整索引文件到 index.php。实际上，如果你完成了 step 9，这里会有一个“不是合法的索引文件”的警告。直到你重新调整索引文件为合法文件。

11. 在“项目属性”的“PHP 包含路径”中设置你的 Zend Framework 路径。例如从 svn 导出的某个路径 ~/Zend Framework\library。

12. 至此已经基本设置完成，需要注意的是“项目属性”中的“调试服务器端 PHP”和“调试客户端 JavaScript” 需要勾上才可以正常调试。

简单测试一下代码编辑和调试的情况：

漂亮完整的代码提示，包括方法或属性类型、参数、所在的类名或文件名等等。同时还会解析 phpdoc。

强大的单步调试，我以前说过 php 让我头疼的就是调试。虽然 xdebug 很完美，但是所有调试器都有这样那样的不足。现在 netbeans 带来的是 java style 的调试方式，很好，很强大。

变量的监视信息详实准确，无需再为一个变量的值而 echo 来 var_dump 去了。

总体上来说，netbeans 6.5rc for php 是我见过的比较好的 IDE for php 之一。即便我坚信 IDE is evil ，netbeans for php 也让我眼前一亮。再配合其他插件如 svn、uml、database，已经无需其他工具辅助即可完成 php 日常开发所需。不过试用之后，也发现一些不足的地方：比如有一些提示框中英文混杂在一起；新建 php 工程的向导设置也过于简单，以至于建立 Zend Framework 项目时需要建立好后再次调整项目设置；又比如会莫名其妙的提示一个临时目录下某文件无法访问；再如代码提示时不能正确解析魔法方法，无法提示魔法方法提供的魔法属性等等。不过相信在正式的 6.5 版中这些问题都会一一得到解决，作为一个 rc 版本的软件来说，netbeans 已经做得够好了。

我计划在 PNP-广州 PHP 街坊群中推荐 netbeans 作为初学 Zend Framework 的平台，这样可以利用强大的单步功能，和代码提示功能来学习 Zend Framework，了解 Zend Framework 的运行机制。不知道大家对此有什么看法和意见，欢迎讨论。

PS: 推荐 eclipse 的朋友务必请考虑一下我那只有 512M 内存的本本，当时选择用 netbeans 写 java，就是因为它不是那么消耗内存和 cpu。

[2008-07-04] 中文版本 chm 发布 1 周年，今天截止，中文翻译进度是 71%。同时也编译了英文版本。
中文 Zend Framework 手册 CHM 版本 | 英文 Zend Framework 手册 CHM版本

同时在 SVN 的中文手册目录下增加了 tools 目录，其中包含了正确编译中文 CHM 的说明以及工具。直接访问 SVN 的朋友可以自行编译。

英文 Zend Framework 手册 CHM

下载 Zend Framework 手册

但是我仍然建议大家看英文手册，关于 Zend_Db 部分那个 Bug 管理的例子在最新的英文手册中已经添加了详细说明和表结构 E – R 图

英文 Zend Framework 手册 CHM

补充：火大！火大 ！越看中文版本越火大。于是为了给自己用又编译了英文的版本。 英文 Zend Framework 手册 CHM

5月23日對于 Zend Framework 來說絕對不是什么好日子。

首先 Darby 找到了新工作，23 日就離開了 Zend。

其次，Zend Framework 的 SVN 似乎受到毀滅性的損壞。

本想給大家再編譯一個英文版的 Zend Framework 手冊，現在看來，只能等 SVN 恢復再說了。

最新消息，Matthew 移動了 trunk 到 standard/trunk。所以之前的 svn 無法正常使用。

今天才知道這個消息，1.5 做了很多改動，包括路由部分的大小寫解析方式也同以前 1.0x 不同。新功能對于只用 Zend Framework 開發普通網站的人來說并不是十分要緊。Zend_Form 和 Zend_Layout 反而會增加頁面編輯的難度。

* New Zend_Form component with support for AJAX-enabled form elements
* New action and view helpers for automating and facilitating AJAX requests and
alternate response formats
* LDAP, Infocard, and OpenID authentication adapters
* Support for complex Lucene searches, including fuzzy, date-range, and wildcard
queries
* Support for Lucene 2.1 index file format
* Partial, Placeholder, Action, and Header view helpers for advanced view
composition and rendering
* New Zend_Layout component for automating and facilitating site layouts
* UTF-8 support for PDF documents

對于我來說修復 bug 比新功能更讓人鼓舞：

http://framework.zend.com/issues/secure/IssueNavigator.jspa?mode=hide&requestId=10661

我查了一下，我之前提交的多數 bug 都已經修復了。

ninny project 在實際使用中發現了很多之前設計考慮不周的地方，我準備徹底重寫。 在可能的情況下會放到 code.google.com 上去。

下载 9月2日的讲义幻灯和代码示例。

在线演示：www.i-fang.com/php/lucene4php/search.php

内容如下：

在PHP中使用Lucene

1. 概述

   1. 信息检索

      1. 三种模型

         1. Boolean

         2. Probabilistic

         3. Vector

      2. 文本处理

         1. 噪声词表

         2. 相关词汇表

      3. 查询

         1. 排序

         2. 辞典

         3. 分类和聚类

   2. Lucene

      1. 介绍

      2. Lucene 起源与发展

         1. 起源

         2. sourceforge.net

         3. apache

      3. 其他版本的 Lucene

         1. CLucene

         2. PyLucene

         3. Lucy

         4. Lucene.net

      4. PHP 可用的 Lucene

         1. Zend Framework Lucene

         2. Pecl CLucene extension

         3. Java Bridge Lucene

         4. XML-PRC or WebService call

2. 实例

   1. 建立索引

      1. 关于索引

         1. 索引的作用

         2. 倒排索引

         3. 多文件索引

         4. 复合索引

      2. 建立

         1. 文档

         2. 字段

   2. 搜索

      1. 分词

      2. 查询语言

      3. 排序

      4. 限制返回结果数目

3. 总结

   1. Zend_Search_Lucene 的限制

      1. 中文

      2. 性能

      3. 跨平台

   2. 更好的实现方式

      1. XML-RPC or WebServcec or HTTP call

      2. Java Bridge

      3. 基于Lucy的PHP extension

许多人说 Zend_DB_Select 是一个丑陋的实现，同时是完全没有必要的。那么我想谈一下我的想法，为什么我们需要 Zend_Db_Select。

首先，假设有一个非常熟悉 mysql 并且一直在其上工作的团队。现在有一个使用 Oracle 的项目需要开发。这个项目非常紧张，没有时间学习新的知识（是的，就像我们一样）。那么他们可以做什么？他们会掉入 SQL 的迷宫中去吗？又或者管理层突发善心给那么一点可怜的时间来学习 PL/SQL 的语法？

Zend_Db_Select 就是救世主。

他们不需要知道如何从 Oracle 中查询从一个记录号到另一个指定记录号之间的数据。只要记得 $select->limit($start, $end); 可以做到。这同 mysql 很像不是么？统一的 SQL 界面隐含了不同数据库之间的差异。开发人员不用天天为了各种数据库间 SQL 语法差异而努力奋战。也不用为了单引号、双引号、反引号在苦恼。因为 Zend_Db_Select 会处理这些。

又或者在一个很久以前写的已经关联了5个表的 SQL 语句中增加一个 left join。如何呢？不知道你有没有试过调试了半天，只是由于疏忽将新加入的 join 语句放在了 where 的后面？Zend_Db_Select 不需要你来考虑分解 SQL 语句把 join 语句放到合适的地方。只要在查询前的任何一个地方调用 $select->joinLeft(…) 问题解决了。Zend_Db_Select 会自己解决顺序问题，生成合法的 SQL 语句。

真正的高手一定会藐视上面的原因而拒绝使用 Zend_Db_Select 。因为他们永远不会遇到没有充裕时间学习的项目，或者需要使用不熟悉的数据库进行开发的项目。同时，他们也不会犯那种写错顺序的错误。因为，他们是高手。

但是，下面的原因似乎难以抗拒。

PHP 自身并没有一个健全的、统一的数据库接口。于是，当我们希望实现如 ORM 或 Data Table Gateway 这样的功能时，应该怎么做呢？没错，使用 PDO 或者 mysql、mysqli、oci8……自己来封装实现。嗯，嗯，我知道不少框架实现了很高级的数据库操作方式。但是只能用在 mysql ，或者很难移植到其他数据库。那么要给这些框架增加一个数据库支持呢？从头写吧，反正原理基本类似，换一换 SQL 语句，改一改功能实现……这样的程序健壮么？这样的数据库支持好么？或许用过一些其他数据库的朋友知道，不少框架在 mysql 上是龙，在其他数据库上是虫。

Zend_Db_Select 解决了这个问题，不需要再去管什么该死的引号，不用管分页查询是 TOP、LIMIT 还是BETWEEN row number。不论什么数据库，在 Zend_Db_Select 的写法是一致的。统一的 SQL 表达方式，换来的是更加内敛的数据库部件。开发 ORM 也好，开发 DTG 也罢，只要基于 Zend_Db_Select 的查询方式，就能保证在所有 Zend_Db_Adapter 支持的数据库上都可以用。开发人员可以更专注于数据库操作功能的实现，而不是 SQL 语句的兼容性问题。

当然了，有的高手也说过：这个内容，Db Driver 层就可以处理了何必要多搞出来一个 Db Select？不伦不类，不是多写几个 -> 就叫面向对象了。

Db Driver 或者叫 Db Adapter 可以来实现，这是没有错的，但是对于一些 ORM 或 DTG 不好实现或无法实现的功能，例如信息系统中最为常见的复杂报表、嵌套报表等又如何呢？手写 SQL 是吧？那又回到之前说过的那两个麻烦上面了。

哦，对不起，忘了，高手，高手是不会遇到这种问题的。

综上所述，Zend_Db_Select 并不是一些所谓的高手口中的鸡肋。其实是 Zend Db 的一个不可缺少的坚实基础。在这个基础之上可以由开发者自由发挥，而不需要过多关注实际的 SQL 书写规则。难道还有不使用它的理由么？

原文在此：http://hi.baidu.com/thinkinginlamp/blog/item/6282d539d96198f13a87ced1.html

在这里对有效内容略做剖析，谈谈我的看法。另：为避免被“河蟹”，所以原文中那另外的 50% 的废话我就不说了。

第一宗罪：言而无信

原文：Zend Framework也是一样。在Zend Framework发布之前，曾给广大PHPer画了一个看上去很美的饼：一个ActiveRecord的PHP实现。可当Zend Framework发布之后大家才发现，这不过是一 个很普通的DAO实现罢了，不是说DAO实现就差劲，但是作为“官方”，不能信口雌黄。最近，越来越多的开发者开始认为Zend Framework已经不是框架，而是一个类库的集合，面对这种情况，Zend Framework团队出来辟谣说绝对不会。我们是否还应该相信他们的话呢？！”

对于开源世界，跳票的事情是屡有发生。比如 FreeBSD 啦、Debian 啦……我是习惯了。Zend Framework 发布之前确实曾经制定过一些目标，发布 1.0 的时候没有实现。不过，我不认为 zf 1.0 就是 final 版本，我也不认为 Active Record 在被列为淘汰技术之前没有可能在 zf 中实现。至于类库集合这个说法……什么是框架？什么是类库集合呢？如果不解释清楚这两个概念，那多说无意啊。pear 所出现的麻烦就是结构混乱，耦合高。你要用一个包，可能关联的包就有十个八个。很难单独的将一个包提取出来。而类库集合，很多开发有个两三年的朋友手头都有。雪藏的一些好用的包，平时不给人看，关键时刻那是用来当大侠的资本呢。但是这些雪藏，相互之间没有关联，确实底耦合，不过要放在一起用用……嗯，嗯……还是要花点心思的。

第二宗罪：不自量力

原文：Zend Framework也是一样。打开Zend Framework的软件包，里面能找到各种各样的类库：如制作pdf的类库，还有诸如Akismet, Amazon, Audioscrobbler, Delicious, Flickr, Simpy, StrikeIron and Yahoo!等WebService相关API。这是框架该做的事情么？就算做好了，以后能保证长期维护它们保持稳定安全么？更重要的是，这里面相当一部 分功能都是和Pear或者其他开源类库功能重复的，面对重复发明轮子的行为，我们总是要发出疑问的，Zend你为什么要这么做？难道你想剿灭Pear，建 立大东亚共荣圈？！

貌似，这个说法我不是第一次听说了。Zend Framework 含有大量看似无关紧要的内容。其实 Zend Framework 自身的松耦合也允许使用其他任何包进行扩展。这可比其他耦合度相对高很多的框架来说要强一些了。比如如果使用 log4php 和 自己写的数据库类进行开发，许多现在流行的框架都将死掉。因为，你根本无法将数据库类从框架本身剥离。或者剥离以后，框架所剩无几了。而重复 pear包或者其他一些开源项目的内容，就我的理解，主要是 go to php5。 pear 中的大部分包（应该说所有的）都不是按照 php5 的语法进行编写的。再说了，多一个选择不是更好？为什么自己在不断重复造轮子的时候，不允许别人也过过瘾呢？而且，就 zf 开发组从来没有用什么”官方“，”权威“之类的发表过任何东西。倒是国内一些别有用心的人，不时的把这些词和 zf 拉扯到一起。何来共荣圈？别紧张，不是说你。^_^

第三宗罪：自欺欺人

原文：Zend Framework也是一样。在这个号称官方的MVC框架中，我们看不到M在哪里。或者说Zend Framework的M相当松散，它推崇的理论是胶水概念，M里用什么就拿过来粘上，好像盖房子一样，一块砖一块砖的垒，中间用泥巴粘上，但是别忘了，现 在盖大楼都是钢筋混凝土结构了。虽然Zend Framework追求的就是All In One的效果，但是恰恰在这一点上，它缺失了最重要的东西，抛开它类库的嫌疑不说，即便算它是框架，也不过是一个先天残疾的框架。

许多人的概念中，MVC 框架就是有 M 有 V 有 C。缺一不可。恩，我之前也是这么想的。但是话说回来了，这个 M 可是模型啊，除了数据模型还有业务模型等等。框架怎么能知道你需要什么样的模型，你需要的模型应该是什么样？说实话，许多人在开发做完了都不知道自己项目中的模型应该是怎么样。许多人指责 zf 说缺失 M 部分。但是我压根没想明白，哪个框架是有完整的 M 呢？如果有完整的 M 了，还要咱们这些编码工人做什么呢？呵呵，矛盾了不是？如果这里所谓的 M 就是指 RoR 之流，那是不是又太狭义了一些？

不少人说我是 zf 的铁杆。我不否认我很喜欢 zf。但是我不是铁杆。每天都能在 zf 中能找到大量的低级的编码错误就足以让我觉得：关爱生命，远离 zf。

我只是觉得，一些高手不应当用一些不负责任的言行来误导希望进一步学习的朋友。更不应当打着善意的旗号，做猥琐的事情。有不足，应当指出，而不是用一些大道理，高帽子来套。那样，世界上就没有任何一个框架有存在的必要了，不是么？

总之，愈加其罪，何患无辞？zf 确实有许多不足，但是不要一说就是”发展思路有些偏差“这样的大而空洞的泛泛之谈。这种话，看两篇技术文章，学两个时髦的词汇，就是一行代码没写过的人也会说。不如来一些更加实际的东西：xxx框架中是如何如何实现 xxxx，这样有 xxxx 的好处。而 zf 并没有这样实现，它是 xxxx 这样实现的，这样有 xxxxx 的坏处。或许更容易让我这样没事爱找茬的人闭嘴哦～～