1.6版本的zf终于将SOAP放进来了，同时也增加了DOJO的支持。不过我没有想通。为什么那么多的JS框架，最终会选择了DOJO。

这些不是我能够想得通的。还是看看到底更新了什么再说吧。

An overview of new features:

• Dojo Integration
  • JSON-RPC
  • Dojo Data packing
  • Dojo View Helper
  • Dijit integration with Zend_Form & Zend_View
  • Dojo Library Distribution
• SOAP
  • SOAP Server
  • SOAP Client
  • Autodiscovery
  • WSDL access
  • WSDL Generation
• Preview of Tooling Project in Laboratory (see /laboratory folder)
  • Command Line Interface
  • Project Asset Management
• Unit Testing Harness for Controllers
• Lucene 2.3 Index File Format Support
• Zend_Session save handler for Database Tables
• Paginator Component
• Text/Figlet Support
• ReCaptcha Service
• Zend_Config_Xml Attribute Support
• Character Set Option for DB Adapters
• Zend File Transfer Component
• New Media View Helpers (Flash, Quicktime, Object, and Page)
• Support in Zend_Translate for INI File Format

This obviously marks a very important step towards a high-quality, highly tested 1.6 GA release. Thanks to everyone who has contributed to this release in any way: with patches/check ins, documentation/translations, and bug reports.

But our work is not yet over! Let's do our best to bring this release to the breaking point to find areas we can improve the release for General Availability. Based on your feedback we will determine in the next few weeks whether we require additional release candidates, so please provide feedback on our issue tracker (http://framework.zend.com/issues) as soon as you can and ask any questions/post your experiences on the appropriate mailing list.

Again, the Zend Framework community does NOT recommend this release for production use. We do, however, recommend evaluating new features in this release with existing and new applications.

Enjoy 1.6RC1, and see you on the issue tracker, wiki, and mailing lists!

————END————

不知道：Zend File Transfer Component，这个会给我们带来什么样的惊喜？大文件传输还是其他的？下载源码研究一下，哈哈

原文地址：http://devzone.zend.com/article/3509-Zend_Acl-and-MVC-Integration-Part-I-Basic-Use

原文内容：

By Aldemar Bernal

So, what is wrong with Zend_Acl and the current MVC implementation in the Zend Framework? there is nothing wrong, it is just that it gets not too obvious for developers how to achieve an optimal integration between these two important parts of the framework.

First at all, this article is based on the following Zend Framework Proporsal (link), by this moment this proposal is in Pending Recommendation state.

Well, how it works? There are two key components in this proposal:

1. A Front Controller Plugin: This component resolves if the current user has access to the page which is being opened.
2. An Action Helper: This component allows you to check whether the current user has access inside a controller.

Based on these two components, let's try them with an example. Let's talk about a website like DevZone, we would need a controller that work with the user management and another one which will deal with article management, as well we need 3 types of users (roles), one for guests, one for writers and another one which will approve the articles; resuming, we have:

Resources:

1. user controller.
2. article controller.

Roles:

1. Guest.
2. Writer.
3. Admin.

Setting up the Zend_Acl component

After defined what we want to do, the next step will create a Zend_Acl instance which will reflect our model.

/** Creating the ACL object */
require_once 'Zend/Acl.php';
$myAcl = new Zend_Acl();

Creating the roles

Now we create the roles in our Zend_Acl instance.

/** Creating Roles */
require_once 'Zend/Acl/Role.php';
$myAcl->addRole(new Zend_Acl_Role('guest'))
      ->addRole(new Zend_Acl_Role('writer'), 'guest')
      ->addRole(new Zend_Acl_Role('admin'), 'writer');

Creating the resources

And then we create the resources needed (one per controller) and their relationship with the roles we created.

/** Creating resources */
require_once 'Zend/Acl/Resource.php';
$myAcl->add(new Zend_Acl_Resource('user'))
      ->add(new Zend_Acl_Resource('article'));

Creating the permissions

Now that we added the roles and resources to our Zend_Acl instance, it's time to explain what actions must be available to which roles.

1. Guest won't have access to edit, add or approve an article.
2. Writer won't have access to approve an article.
3. Admin will have complete access.

/** Creating permissions */
$myAcl->allow('guest', 'user')
      ->deny('guest', 'article')
      ->allow('guest', 'article', 'view')
      ->allow('writer', 'article', array('add', 'edit'))
      ->allow('admin', 'article', 'approve');

Creating the access denied view file

We will need to create a view and an action which will address all those denied users, in order to do it, first we create a new action in our error controller:

class ErrorController extends Zend_Controller_Action
{
    ....

    public function deniedAction()
    {
    }

    ....
}

And then we create our view file (/application/views/scripts/error/denied.phtml) with some warning message:

<h1>Error</h1>
<h2>Access denied</h2>
<p>You are trying to access an area which you have not allowed.</p>

Finishing the configuration

Okay, we have setup our Zend_Acl configuration, so far, it doesn't look like something new, but the next step is register the controller plugin, this important part takes the Zend_Acl instance we created and then validates it against the current page being accessed by an user.

/** Setting up the front controller */ 
require_once 'Zend/Controller/Front.php'; 
$front = Zend_Controller_Front::getInstance(); 
$front->setControllerDirectory('path/to/controllers'); 
 
/** Registering the Plugin object */ 
require_once 'Zend/Controller/Plugin/Acl.php'; 
$aclPlugin = new Zend_Controller_Plugin_Acl($myAcl);
$aclPlugin->setRoleName($currentUserRole);

$front->registerPlugin(new Zend_Controller_Plugin_Acl($acl, 'guest')); 

/** Dispatching the front controller */ 
$front->dispatch();

After this configuration is done, once an user enters in our application, depending the role he/she has the page will be displayed or an access denied page will be displayed.

For more information about this you can go to:
Zend_Acl & MVC Integration
and here is a small implementation source code of this:
Source Code

————END————
由于本文并没有什么特别的地方，而且单词也没有什么，故不作翻译。

偶在网上闲逛。突然发现一段内容，对应家中现有的有线电视情况，突然感到好紧张。。。贴上部分内容，陪我一起震惊吧。

写代码的时候不可避免的会使用到注释。大多数的情况下，我们都是使用<!-- 这里是注释 -->，因为这是HTML自带的注释功能，在这里的代码都不会被显示到浏览器。

然而，使用了smarty之类，我们确实不是很建议这样使用，因为，在<!---->标记里的smarty代码其实还是被解析了，如果是这样的话，那么，我们其实是多做了很多事情，却没有被显示出来，那就是说，我们其实多做了很多无用功。

因此，我们在使用smarty模版的时候，应该根据smarty的规范来。让我们看看手册怎么说：

 所有例子中，我们假定你使用缺省的分隔符。Smarty中，所有在分隔符之外的内容被显示为静态内容，或者说不会被改变。一旦Smarty遇见分隔符，它将尝试解释它们，然后在其位置处显示合适的内容。

注释

    模板注释由星号包围，继而由分隔符包围，型如：{* 这是一个注释 *}。Smarty注释不会在最终模板的输出中显示，这点和<!-- HTML comments -->不同。前者对于在模板中插入内部注释有用，因为没有人能看到。;-)

smarty中的变量和平时使用有点区别，比如$aa.bb其实代表的是$aa['bb']，具体如何个使用法，其实在手册里已经有详细说明了

    Smarty可以识别嵌入在双引号中赋值的变量，只要变量名只包含数字，字母，下划线和方括号[]（参见命名）。如果有其它字符（如句点，对象引用等），变量必须由反引号对`backticks`包含。你不可以嵌入修饰符，它们必须永远在引号之外使用。

实际使用中应该是这样的：

语法例子：
{func var="test $foo test"}       <-- 使用$foo
{func var="test $foo_bar test"}   <-- 使用$foo_bar
{func var="test $foo[0] test"}    <-- 使用$foo[0]
{func var="test $foo[bar] test"}  <-- 使用$foo[bar]
{func var="test $foo.bar test"}   <-- 使用$foo（不是$foo.bar）
{func var="test `$foo.bar` test"} <-- 使用$foo.bar
{func var="test `$foo.bar` test"|escape} <-- 修饰符在引号外！

实际例子：
{include file="subdir/$tpl_name.tpl"} <-- 将以实际值替换$tpl_name
{cycle values="one,two,`$smarty.config.myval`"} <-- 必须有反引号！

看清楚哦。平时在使用的时候应该是感觉不出问题的，只有用在函数、循环里面，这才会成为使用中的问题。