It's also feasible to manipulate views in fairly flexible fashion by appealing to the niceties of a few other patterns as well, including the rather underrated Decorators. If you're wondering in what parallel universe Decorators get along with views, in this part I'll be showing how to put them to work side by side in nice orchestration to bring to life yet another view module.

They create a simple example where an HTML element (based on an interface) is rendered - a span tag - with content passed in on creation. They take this same logic and transfer it over to the View handler, making handlers for difference pieces of the content (outer and inner). These decorators are then passed in the data from the view and rendered in order.

If you've been using Zend Forms for any length of time, you'll know just how flexible and configurable they are. [...] We can, as I'm quite fond of, use the ViewScript decorator. This allows us to have nearly 100% control of the configuration of the look and feel of our rendered forms.

The ViewScript decorator lets you have full control over the layout of your form, letting you use a view (file) to define the markup for the form and injecting your elements into it. There is an issue with using the form in other modules though - it can't find the view file by default. The solution is to pass in a viewModule when using the form, showing it where it can find the view.

A common problem that developers face when building applications is how to allow the application to be "plug-able" at runtime. Meaning, to allow non-core code to modify the way an application is processed at runtime. There are a lot of different ways that this can be done, and lots of examples of it in real life. Over a year ago, I wrote a StackOverflow Answer on this topic. However, I think it deserves another look. So let's look at some patterns and common implementations.

The patterns he covers are:

• Observer
• Mediator
• Strategy
• Decorator
• Chain of Responsibility

For each there's both a bit of sample code showing it in use and links to some examples from various frameworks and other projects.

It is a fantastically productive framework, one which I happen to use almost every single day. There was however one feature which absolutely drove me crazy. The Zend_Form component's uses the dd, dl, and dt elements as the default form markup decorators, meaning that even a simple contact form consisting of name, email, and message fields and a submit button [is marked up with dl, dt and dds]. [...] It goes without saying that the overwhelming majority of developers do not use these elements to mark up their forms, with the sheer number of questions posted to StackOverflow and elsewhere about getting rid of these decorators backing this assertion.

He gives his simple solution to the issue, something better than removing all of the decorators and using setDecorator to replace them - a simple partial view that echos out the fields directly. The trick is to use the setDecorators call with a "ViewScript" option pointing to your partial and setElementDecorators() call to use a "ViewHelper".

Within the Design Patterns world, there are four main categories: Architectural, Structural, Creational, and Behavioral. Architectural patterns describe the system as a whole, Structural patterns describe the relationships between objects, Creational handle creating objects, and finally Behavioral describe the communication patterns between objects. Each of the categories is worth discussion on its own, but in this case we'll stick to the Structural patterns of Adapter, Facade, and Decorator.

He describes each of the patterns (no code in this one, just descriptions) and for each mentions some of the tools that the Zend Framework has to offer that match up. For example, the Adapter pattern is used in quite a few places in the framework including in the Zend_Db component for the connection types to different databases.

The idea is to solve the same problem I had when I wrote the previous article. I want to protect the execution of certain functions in a class to only being executed if the user is logged on. [...] The solution with interfaces is clean and simple (no extra libraries need and no reflection need too). The problem is that I can use it only for all the functions of the class.

He gives an example class with four different methods (one with annotations) and his annotation parsing class that runs the predispatch and postdispatch methods based on those annotations. He also shows another examples using an abstract class.

Continuing my series on PHP design patterns, today it's the turn of the Decorator. In contrast to last week's Strategy Pattern which is used to change the '�guts'� of a class, the Decorator Pattern is used to extend the behavior of a class with different functionality at run time. This is achieved by implementing a '�decorator'� class that implements the same interface as the object that you wish to '�decorate'� and wraps it's content.

The Decorator pattern lets you "decorate" your objects with additional features. He illustrates with a sample "Property" class (that implements an interface) that he wants to extend past the normal property handling. He add a "PropertyDecorator" to the mix that lets it use deocrators for uppercasing and padding the string. There's an example script included at the end that shows how to put it all to use.

Design patterns are optimized, reusable solutions to the programming problems that we encounter every day. A design pattern is not a class or a library that we can simply plug into our system; it's much more than that. It is a template that has to be implemented in the correct situation. It's not language-specific either. A good design pattern should be implementable in most - if not all - languages, depending on the capabilities of the language.

They introduce a few of the more widely used patterns including the strategy pattern, adapter pattern, factory methods, decorator and singleton patterns. Each comes with a bit of code showing how it would work and a "where would I use this?" section with a better example.

This little video tutorial should set you up for building your own custom Zend_Form decorators in 15 minutes. I'll show you how you can make the necessary class and have it easily added to your existing Zend_Form_Decorator configuration.

If you'd like to follow along with the tutorial as he walks through it you can grab a copy of the source or, for other examples, look through their repository.

In my last post on decorators, I had an example that showed rendering a "date of birth" element [...]. This has prompted some questions about how this element might be represented as a Zend_Form_Element, as well as how a decorator might be written to encapsulate this logic. Fortunately, I'd already planned to tackle those very subjects for this post!

To be able to use the element in its current state the key lies in the setValue method. More correctly in the overriding of the setValue method. He includes an example class that is smart enough to use that custom form element. It has get and set methods for each of the date fields (month/day/year) and the set/getValue methods that can interact using them. He wraps this all up inside a form decorator and creates an instance of the Date element to help create and handle the properties it has.