Author: 芳草苑主

Magento 里的namespace, module name, controller name, action name, class name, function name, model name, router name, xml identifier name, etc, etc 实在太过复杂，凭我的脑袋实在记不全什么时候该大写，什么时候该小写，什么时候该加一个下划线。

为了不出错，我尽量照抄 Magento source code，比如 extend Mage_Catalog 模块时，我取名 Myname_Catalog。我这个模块名作前缀重写了一些 Model 和 Block，没遇到问题。最近在重写 Controller 时，出问题了——如用/catalog/product/view/id/1 能执行重写后的 controller；但用/seo-product-page-name.html 却执行了重写前的 controller。这问题不一定是命名引起的，但我在寻找解决方案时意识到要有一个好的命名习惯。

简言之，网上讨论比较多的 Magento upgrade safe 重写规则只适合 Model 和 Block，不适合 Controller。要写出 upgrade safe Controller 也不难，就是谈的人少，不容易找到适用于最新版 Magento 的文档。有空我整理一下如何在 Magento 1.3 下重写 controller，但这不是我今天想说的话题。

我只想说我在重写 Controller 时意识到命名习惯。命名时肯定是用自己的 namespace，但也建议不使用原模块名。比如要重写 Mage_Catalog，不妨使用 Myname_Catalogue，这样最大程度地避免了可能的名字冲突。

I’m quite happy to override Magento models and blocks. Since overriding controllers is different from overriding models and blocks, I do not want to touch it until recently.

What I was trying to achieve was a customised product view page which could show different content according to url parameters and login status.

At first, it was Block detecting url parameters and login status. If the criteria did not meet, Block add an error message and show default content. Then I found this error message would not show up (until next page) because this Block was after Message Block.

So, for the sake of logic, I have to rewrite the product view controller. And it makes more sense if I conduct a redirect rather than show default content if the criteria do not meet.

我喜欢 Zend_Form 这个组件，为了在 Magento 里使用 Zend_Form，走了不少弯路，但最终方法是很简单的。

要在 Magento 里使用 Zend_Form 最关键的一点是明白 Zend_Form 依赖于 Zend_View，而 Magento 从头到尾都没有用到 Zend_View。如果使用 Zend Framework Bootstrap，它会搭建好 MVC，在你想到去用 Zend_View 之前，它就已经就位了，所以 Zend_Form 在真正的 Zend Framework 里是取之即用的。在 Magento 里，必须自己初始化一个 Zend_View，传递给 Zend_Form 的 $_view，或者用 setView()方法，否则你会得到一个错误提示：ViewHelper decorator cannot render without a registered view object。

我走的弯路是刻意在 Magento 里照搬 Zend Framework 里 Zend_Form 的输出。我专门建了 views 这个目录，在其下又建了scripts 目录（Magento 里最接近 views/scripts 的目录是 templates，但我不想把 Zend Framework 那套文件与 Magento 的文件混在一起），然后把初始化后的 Zend_Form 赋值给 $view->form，然后在 views/scripts/index.phtml 里

echo $this->form;

然后在 Magento 的 Block 文件里新建一个方法

public function getZendView() {
	return $this->view;
}

最后在 Magento template 文件里

echo $this->getZendView();

虽然能运行，但过了一天，我自己都觉得不对头，尝试着直接在 Magento 里输出 Zend_Form，也成功了。具体做法是：

先为 Zend_Form 创建一个目录，我把它建在 {MyModuleName}/Model 下（我见 Magento 把与 Form 相关的文件归入 Block，但调用 Block 文件没有调用 Model 文件方便。既然如何在 Magento 里使用 Zend_Form 属于我的原创，在不违背 Magento 文件规范的情况下，我应该有自己的自由决定。再说把 Form 对象归于 Model 也不违背 MVC 的原则）。

然后在其下建了一个 helpers 目录，即 {MyModuleName}/Model/Form/helpers（若不涉及自定义 helper，则跳过此步骤）。选择这个位置，我对自己都有争议，但总得为 Zend_Form 的 ViewHelper 文件找个地方。我在 Zend_Form 里初始化 Zend_View，而 Zend_View 需要知道 ViewHelper 文件的位置，我可以用很简单的dirname(__FILE__) . ‘/helpers’ 得到这个位置。如果放在 Magento 自己的 Helper 目录，则搞混了 Magento Helper 与 Zend ViewHelper，而且我用不着用 Mage::helper(‘mymodulename’) 去调用它。所以我决定在 Form 目录下放置 helpers 目录，以后若把 Form 迁移位置，helpers 也可以随之迁移，方便 refactoring。

然后创建 Zend_Form，在 Block 里用 $form->render() 得到这个表单的 html 输出，最后在 template 下该怎么做我就不多说了。