小的纪念球. Show一下. 

3. Zend Controller之Router
[English Version]

Router的核心工作非常简单. 便是从请求的参数中为Zend_Controller_Front产生Zend_Controller_Dispatcher_Token. Zend Framework默认的Router是通过解析请求的URI来处理的. 如http://your.com/test/add会被解析成一个叫”TestController”的Controller和controller中一个叫”addAction”的方法. controller信息和action信息及其他参数将被封装成Zend_Controller_Dispatcher_Token.
在我们知道原理以后, 我们可以非常轻松的写我们所需要的router. 如, 当我们的web server不支持url_rewriter的时候我们需要一个NoRewriterRouter. 而当我们在一个虚拟主机的子目录里, 那么我们可能需要一个SubDirectoryRouter..

在diggmore的开发过程中, 我写了一个SubDirectoryRouter. 和最初在maillist里流传的稍有不同, 稍微严谨一些.

/**
*
* Sub Directory Router for diggmore
*
*/
class SubDirectoryRouter implements Zend_Controller_Router_Interface
{
//

private $sub_directory;

public function setSubDirectory($sub_directory)
{
$this->sub_directory = $sub_directory;
return $this;
}

public function route(Zend_Controller_Dispatcher_Interface $dispatcher)
{
//
$path = $_SERVER[’REQUEST_URI’];
if (strstr($path, ‘?’)) {
$path = substr($path, 0, strpos($path, ‘?’));
}
$path = explode(’/', trim($path, ‘/’));

$start = 2;

if ($this->sub_directory != ”)
{
//
$tmp = explode(’/', trim($this->sub_directory, ‘/’));
$start = sizeof($tmp) + 2;
}
$controller = $path[$start-2];
$action = isset($path[$start-1]) ? $path[$start-1] : null;

$params = array();
for ($i=$start; $i $params[$path[$i]] = isset($path[$i+1]) ? $path[$i+1] : null;
}

$token = new Zend_Controller_Dispatcher_Token($controller, $action, $params);

if (!$dispatcher->isDispatchable($token)) {
throw new Zend_Controller_Router_Exception(’Request could not be mapped to a route.’);
} else {
return $token;
}

}

}

(more…)

First thanks a lot to my colleague, Eunge. He helped me to solve this problem. And it’s really a long time I haven’t written .Net codes.

Sometimes we need to get InnerXML from the XPathNodeIterator, especially when you are writing codes in XSLT.

If you are using .Net Framework 2.0, it’s very easy. There is a property, InnerXML, in XPathNavigator, and from disassembled code we could find new functionalities of XMLWriter. But if you are using .Net 1.1, it’s really not quite convenient to do it. And there are two concrete classes which inherit abstract class XPathNavigator. One is XPathDocumentNavigator, the other is DocumentXPathNavigator. There is an important difference between two classes. DocumentXPathNavigator implements the interface IHasXmlNode, but XPathDocumentNavigator not. That means if your XPathNavigator is DocumentXPathNavigator, it’s easy to get InnerXML.

[code=csharp]
XPathNavigator nav = dom.CreateNavigator();
// do some select
String innerXml = ((IHasXmlNode)nav).GetNode().InnerXML;
[/code]

(more…)

No only sick Qihoo.
很久以前, 我和xsharp, iCer就对eachnet, taobao这样的网站列出购买记录而非常不满. 因为那是我的隐私, 虽然注册条款里有说明, 但当你需要某服务, 而你又反感的时候, 这通常让人非常郁闷. 如果这里有个选项用于是否显示, 那么我真的会非常非常高兴. 其实各个网站出卖或者利用注册用户信息已经不是秘密, 甚至是大家都知道都做的事实了. 但在中国这样的隐私是从来没有得到真正的保护. 当Qihoo这样的所谓社区搜索开始推出的时候我就非常反感.

1. 不知道Qihoo是否有Robot协议, 社区是否可以不被他所抓取.
2. 那些”社区主”在加入Qihoo的时候, 是否有通知所有注册用户, 社区将被改变, 而让用户选择是否继续参加这个社区.
3. 社区的注册协议里是否有会被搜索引擎抓取, 被Qihoo抓取的事项
4. Qihoo会怎么利用这些抓取的数据?

就社区本身而言, 本来就是相对隐私的. 而对于中国的社区, 论坛, 搜索引擎, 我一向地不信任. 

谈谈我一般怎么保护隐私:

1. 只对自己信任的网站, 公司填写真实, 涉及隐私的信息. 如Calendar.
2. 使用不同的注册名.
3. 绝对不相信任何免费服务. 如免费发短信(这个服务牺牲的不是你一个, 而是至少2个). 像365kit这样的服务我也基本是肯定不会选择的.
4. 填写表单之前认真阅读协议.
5. 不被小利益所诱惑.

UI: XUL
Business: XSLT+Script (or any other languages can be used in XSLT)
Data: XML

That’s cool. 注意, 这几个技术不是用来搭建框架的, 而是用来开发应用的. 另外我相信这一天不远了.

每次和RainX同学聊天都颇有收获, HoHo.

虽然Logo上写着Released. 但实质上还是beta的. 有很多地方还要修改. 比如Tag那块.

总结一下这次主要的工作:
1. 写了模板和CSS文件. 最酷的是整个width是926px. 这可以算是我第一次认认真真仔仔细细从头写完CSS, 颇为得意.
2. 把GeSHi集成了进去, 加强代码格式化.
3. 用上了Nio的Anti Spam Image.
4. 把Wordpress升级到2.0
5. 写上了一些JS, 让Comments有点色彩的变化.
6. 做了个丑丑的Logo. 为了区别与Web 2.0, 所以是released的. 呵呵. Blog没必要用Ajax, Blog重要的是文字.

That’s All.

有趣的是, Easy同学看完以后, 说了句:”Typic iZz Style”. Very interesting.

“只有Web太无趣了.”
这是我和RainX憧憬完多媒体的互动世界以后的voice. 这里的多媒体仅指目前可见的image, vedio等. 现在所有一切的互动都是基于web的, 虽然web2.0给我们带来了大量的rich client的体验, 但我没法让我的多媒体真正互动.
我们所有的针对multi-media files所做的互动都是基于web的dynamic和static的media file进行的.

现在的rich client都不够multi-, 哈哈. 也许是黑客帝国般的幻想. 但总觉得这一天不远. 说来我还从来没有试用过vista, 决定装个玩玩~

在昨天的全体developer的小会议上, 大家被要求submit ideas for incubator plan, 而且incubator project会牵涉到个人的performance score. 呵呵, 看来世界上不仅仅google在做20% 80%. 现在作为一个小小developer的我, 工作压力骤减, 每天完成几个小时的task就ok了. 应该开始专注一些领域作些research了, hoho.

2. Zend Controller之Front
Zend Controller本身的处理流程较为简单直接. 下图来自HaoHappy的Zend文档中文译本中. 核心流程便如图所示.

但细节上却不尽如此.
首先Zend Framework采用了传统的Front Controller模式来对整个Request的处理进行了封装. 整个Front大致如下图所示.

Zend_Ctonroller_Front中最重要的方法就是dispatch了, 可以看作是一个Application的整个执行中心. 在dispatch方法中, 第一个动作是调用Router来根据Url进行route, 第二个动作便是调用Dispatcher来根据route过来的Action (实质是Controller_Dispather_Token)来进行dispatch, 而这个过程将根据Action的具体信息来循环执行, 即如果所执行的Action返回的还是一个Controller_Dispatcher_Token, 即Action的话, dispatch便会继续执行下一个Action. 这样设计可以实现简单的Action Chain.
同时在route和dispath前后都会通知plugin(s), 以达到各种处理的目的, 比如执行时间的统计, log的记录等等. Zend_Ctonroller_Front中的_plugins属性是Plugin_Broker, 即Plugin代理, 用于真正装配Plugin及执行Plugin, 而Plugin_Broker本身自然也是一个Plugin.

另外要提到一下, 从Front的实现中可以看到一个特性, 即方法都返回自身. 如:
[code=php]Zend_Front::getInstance()
->setControllerDirectory($controllerDirectory)
->dispatch();[/code]

Martin Fowler称之为FluentInterface. 这样的写法有利有弊. 不作讨论.
zendframework