<?xml version="1.0" encoding="UTF-8"?>
<!-- Reviewed: no -->
<sect1 id="learning.form.decorators.simplest">
    <title>Decorator Basics</title>

    <sect2 id="learning.form.decorators.simplest.decorator-overview">
        <title>Overview of the Decorator Pattern</title>

        <para>
            To begin, we'll cover some background on the <ulink
                url="http://en.wikipedia.org/wiki/Decorator_pattern">Decorator design
                pattern</ulink>. One common technique is to define a common interface that both
            your originating object and decorator will implement; your decorator than accepts the
            originating object as a dependency, and will either proxy to it or override its methods.
            Let's put that into code to make it more easily understood:
        </para>

        <programlisting language="php"><![CDATA[
interface Window
{
    public function isOpen();
    public function open();
    public function close();
}

class StandardWindow implements Window
{
    protected $_open = false;

    public function isOpen()
    {
        return $this->_open;
    }

    public function open()
    {
        if (!$this->_open) {
            $this->_open = true;
        }
    }

    public function close()
    {
        if ($this->_open) {
            $this->_open = false;
        }
    }
}

class LockedWindow implements Window
{
    protected $_window;

    public function __construct(Window $window)
    {
        $this->_window = $window;
        $this->_window->close();
    }

    public function isOpen()
    {
        return false;
    }

    public function open()
    {
        throw new Exception('Cannot open locked windows');
    }

    public function close()
    {
        $this->_window->close();
    }
}
]]></programlisting>

        <para>
            You then create an object of type <classname>StandardWindow</classname>, pass it to the
            constructor of <classname>LockedWindow</classname>, and your window instance now has
            different behavior. The beauty is that you don't have to implement any sort of "locking"
            functionality on your standard window class -- the decorator takes care of that for you.
            In the meantime, you can pass your locked window around as if it were just another
            window.
        </para>

        <para>
            One particular place where the decorator pattern is useful is for creating textual
            representations of objects. As an example, you might have a "Person" object that, by
            itself, has no textual representation. By using the Decorator pattern, you can create an
            object that will act as if it were a Person, but also provide the ability to render that
            Person textually.
        </para>

        <para>
            In this particular example, we're going to use <ulink
                url="http://en.wikipedia.org/wiki/Duck_typing">duck typing</ulink> instead of an
            explicit interface. This allows our implementation to be a bit more flexible, while
            still allowing the decorator object to act exactly as if it were a Person object.
        </para>

        <programlisting language="php"><![CDATA[
class Person
{
    public function setFirstName($name) {}
    public function getFirstName() {}
    public function setLastName($name) {}
    public function getLastName() {}
    public function setTitle($title) {}
    public function getTitle() {}
}

class TextPerson
{
    protected $_person;

    public function __construct(Person $person)
    {
        $this->_person = $person;
    }

    public function __call($method, $args)
    {
        if (!method_exists($this->_person, $method)) {
            throw new Exception('Invalid method called on HtmlPerson: '
                .  $method);
        }
        return call_user_func_array(array($this->_person, $method), $args);
    }

    public function __toString()
    {
        return $this->_person->getTitle() . ' '
            . $this->_person->getFirstName() . ' '
            . $this->_person->getLastName();
    }
}
]]></programlisting>

        <para>
            In this example, you pass your <classname>Person</classname> instance to the
            <classname>TextPerson</classname> constructor. By using method overloading, you are able
            to continue to call all the methods of <classname>Person</classname> -- to set the first
            name, last name, or title -- but you also now gain a string representation via the
            <methodname>__toString()</methodname> method.
        </para>

        <para>
            This latter example is getting close to how <classname>Zend_Form</classname> decorators
            work. The key difference is that instead of a decorator wrapping the element, the
            element has one or more decorators attached to it that it then injects itself into in
            order to render. The decorator then can access the element's methods and properties in
            order to create a representation of the element -- or a subset of it.
        </para>
    </sect2>

    <sect2 id="learning.form.decorators.simplest.first-decorator">
        <title>Creating Your First Decorator</title>

        <para>
            <classname>Zend_Form</classname> decorators all implement a common interface,
            <classname>Zend_Form_Decorator_Interface</classname>. That interface provides
            the ability to set decorator-specific options, register and retrieve the element, and
            render. A base decorator, <classname>Zend_Form_Decorator_Abstract</classname>, provides
            most of the functionality you will ever need, with the exception of the rendering logic.
        </para>

        <para>
            Let's consider a situation where we simply want to render an element as a standard form
            text input with a label. We won't worry about error handling or whether or not the
            element should be wrapped within other tags for now -- just the basics. Such a decorator
            might look like this:
        </para>

        <programlisting language="php"><![CDATA[
class My_Decorator_SimpleInput extends Zend_Form_Decorator_Abstract
{
    protected $_format = '<label for="%s">%s</label>'
                       . '<input id="%s" name="%s" type="text" value="%s"/>';

    public function render($content)
    {
        $element = $this->getElement();
        $name    = htmlentities($element->getFullyQualifiedName());
        $label   = htmlentities($element->getLabel());
        $id      = htmlentities($element->getId());
        $value   = htmlentities($element->getValue());

        $markup  = sprintf($this->_format, $name, $label, $id, $name, $value);
        return $markup;
    }
}
]]></programlisting>

        <para>
            Let's create an element that uses this decorator:
        </para>

        <programlisting language="php"><![CDATA[
$decorator = new My_Decorator_SimpleInput();
$element   = new Zend_Form_Element('foo', array(
    'label'      => 'Foo',
    'belongsTo'  => 'bar',
    'value'      => 'test',
    'decorators' => array($decorator),
));
]]></programlisting>

        <para>
            Rendering this element results in the following markup:
        </para>

        <programlisting language="html"><![CDATA[
<label for="bar[foo]">Foo</label>
<input id="bar-foo" name="bar[foo]" type="text" value="test"/>
]]></programlisting>

        <para>
            You could also put this class in your library somewhere, inform your element of that
            path, and refer to the decorator as simply "SimpleInput" as well:
        </para>

        <programlisting language="php"><![CDATA[
$element = new Zend_Form_Element('foo', array(
    'label'      => 'Foo',
    'belongsTo'  => 'bar',
    'value'      => 'test',
    'prefixPath' => array('decorator' => array(
        'My_Decorator' => 'path/to/decorators/',
    )),
    'decorators' => array('SimpleInput'),
));
]]></programlisting>

        <para>
            This gives you the benefit of re-use in other projects, and also opens the door for
            providing alternate implementations of that decorator later.
        </para>

        <para>
            In the next section, we'll look at how to combine decorators in order to create
            composite output.
        </para>
    </sect2>
</sect1>
