If you were following closely in the previous section, you may have noticed that a decorator's render() method takes a single argument, $content. This is expected to be a string. render() will then take this string and decide to either replace it, append to it, or prepend it. This allows you to have a chain of decorators -- which allows you to create decorators that render only a subset of the element's metadata, and then layer these decorators to build the full markup for the element.

如果你紧跟上一节内容，你或许已经注意到装饰器的render方法只接收一个字符串类型的参数$content。render()拿到这个字符串，然后决定是替换它、追加内容还是在前方添加内容。 这样就可以让你使用一串装饰器，每个装饰器只负责呈现元素的一部分，最后层层叠加得到这个元素的全部HTML。

Let's look at how this works in practice.

让我们看一下实际中的工作原理。

For most form element types, the following decorators are used:

对于绝大多数的元素类型，用到下面这些装饰器。

• ViewHelper (render the form input using one of the standard form view helpers). 使用标准的表单视图助手呈现表单元素

• Errors (render validation errors via an unordered list). 通过一个无序列表来呈现验证错误

• Description (render any description attached to the element; often used for tooltips). 呈现所有附加于这个元素的描述信息，一般用于友好提示

• HtmlTag (wrap all of the above in a <dd> tag. 将上面的所有内容包裹在一个<dd>标签中

• Label (render the label preceding the above, wrapped in a <dt> tag. 使用<dt>在上面内容之前呈现这个元素的label标签

You'll notice that each of these decorators does just one thing, and operates on one specific piece of metadata stored in the form element: the Errors decorator pulls validation errors and renders them; the Label decorator pulls just the label and renders it. This allows the individual decorators to be very succinct, repeatable, and, more importantly, testable.

你可以发现上面的每个装饰器各司其职，只负责自己的一件事，只操作元素特定的一部分数据。比如，Errors装饰器只拿到验证错误数据并呈现出来， Label装饰器只拿到标签数据然后呈现出来。这就使得这些相互独立的装饰器非常简洁、可重复，更为重要的是可测试。

It's also where that $content argument comes into play: each decorator's render() method is designed to accept content, and then either replace it (usually by wrapping it), prepend to it, or append to it.

这也就是为什么要有$content参数，每个装饰器的render()方法都接收这个参数，然后要么替换掉、要么在后面追加内容、要么在前面追加内容。

So, it's best to think of the process of decoration as one of building an onion from the inside out.

所以，可以把装饰的这个过程想象成洋葱从内到外的构造过程。

To simplify the process, we'll take a look at the example from the previous section. Recall:

为了更简单的说明这个过程，我们来看一下上一节中的例子。

Let's now remove the label functionality, and build a separate decorator for that.

我们先从中去掉label这部分，然后为label单独建个装饰器。

Now, this may look all well and good, but here's the problem: as written currently, the last decorator to run wins, and overwrites everything. You'll end up with just the input, or just the label, depending on which you register last.

这样看起来不错了，不过还有个问题。按照现在的写法，最后执行的装饰器会覆盖所有内容。你最后要么仅仅得到了input部分，要么仅仅label部分，这就取决于你最后注册的是哪个装饰器。

To overcome this, simply concatenate the passed in $content with the markup somehow:

要解决这个问题，仅仅需要把传递进来的$content变量和$markup变量拼接起来就可以了。

The problem with the above approach comes when you want to programmatically choose whether the original content should precede or append the new markup. Fortunately, there's a standard mechanism for this already; Zend_Form_Decorator_Abstract has a concept of placement and defines some constants for matching it. Additionally, it allows specifying a separator to place between the two. Let's make use of those:

上面这种方法的问题在于如何以编程方式来决定$content和$markup在拼接时的位置前后。 不过，Zend已经存在一个标准的机制解决这个问题。 Zend_Form_Decorator_Abstract定义了一个placement的概念，并为其定义了一些常量。 另外，还允许指定两者拼接时的连接符。

Notice in the above that I'm switching the default case for each; the assumption will be that labels prepend content, and input appends.

注意上面两个装饰器的默认的placement是相反的，label默认置于内容前面，input则默认置于内容后面。

Now, let's create a form element that uses these:

现在我们来创建一个使用了上述装饰器的表单元素。

How will this work? When we call render(), the element will iterate through the various attached decorators, calling render() on each. It will pass an empty string to the very first, and then whatever content is created will be passed to the next, and so on:

上面的内容会怎样运行呢？当我们调用render方法时，元素就会遍历所有绑定的装饰器，逐个调用这些装饰器的render方法。 它会初始传递一个空字符串，然后一直往下传递。

• Initial content is an empty string: ''.

  初始内容是一个空字符串。

• '' is passed to the SimpleInput decorator, which then generates a form input that it appends to the empty string: <input id="bar-foo" name="bar[foo]" type="text" value="test"/>.

  空字符串被传递至SimpleInput装饰器，在空字符串后面生成一个input元素，<input id="bar-foo" name="bar[foo]" type="text" value="test"/>。

• The input is then passed as content to the SimpleLabel decorator, which generates a label and prepends it to the original content; the default separator is a PHP_EOL character, giving us this: <label for="bar-foo">\n<input id="bar-foo" name="bar[foo]" type="text" value="test"/>.

  input元素接着作为内容传递至SimpleLabel装饰器，生成一个label元素并放在原有内容之前。 默认的分隔符是PHP_EOL，因此得到如下内容： <label for="bar-foo">\n<input id="bar-foo" name="bar[foo]" type="text" value="test"/>

But wait a second! What if you wanted the label to come after the input for some reason? Remember that "placement" flag? You can pass it as an option to the decorator. The easiest way to do this is to pass an array of options with the decorator during element creation:

但如果你想把label放在input之后呢，

Notice that when passing options, you must wrap the decorator within an array; this hints to the constructor that options are available. The decorator name is the first element of the array, and options are passed in an array to the second element of the array.

The above results in the markup <input id="bar-foo" name="bar[foo]" type="text" value="test"/>\n<label for="bar-foo">.

Using this technique, you can have decorators that target specific metadata of the element or form and create only the markup relevant to that metadata; by using mulitiple decorators, you can then build up the complete element markup. Our onion is the result.

There are pros and cons to this approach. First, the cons:

• More complex to implement. You have to pay careful attention to the decorators you use and what placement you utilize in order to build up the markup in the correct sequence.

• More resource intensive. More decorators means more objects; multiply this by the number of elements you have in a form, and you may end up with some serious resource usage. Caching can help here.

The advantages are compelling, though:

• Reusable decorators. You can create truly re-usable decorators with this technique, as you don't have to worry about the complete markup, but only markup for one or a few pieces of element or form metadata.

• Ultimate flexibility. You can theoretically generate any markup combination you want from a small number of decorators.

While the above examples are the intended usage of decorators within Zend_Form, it's often hard to wrap your head around how the decorators interact with one another to build the final markup. For this reason, some flexibility was added in the 1.7 series to make rendering individual decorators possible -- which gives some Rails-like simplicity to rendering forms. We'll look at that in the next section.