On his blog today Jason Gilmore has a quick post about solving one of his frustrations with Zend_Form (a part of the Zend Framework) - the default form decorators.

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".

On the Zend Developer Zone there's a new article from Keith Casey where he talks about some of his favorite design patterns he's come across in his time as a developer - adapter, facade and decorator.

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.

Gonzalo Ayuso has a new post to his blog looking at some of the recent work he's done with PHPDoc and annotations to create "function decorators" in his code.

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.

Tom Rawcliffe has posted the latest installment of his look at design patterns in PHP. This time his focus is on the Decorator pattern.

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.

On NETTUTS.com today there's a new tutorial that introduces a bit more advanced concept in the development process - design patterns.

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.

On ZendCasts.com today there's a new screencast aimed at showing off custom Zend_Form decorators for your Zend Framework application.

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.

Based on an example in a previous blog post (seen here) Matthew Weier O'Phinney wanted to clear a few things up on the "date of birth" element he had mocked up in his Zend_Form example.

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.

Matthew Weier O'Phinney has another post in his look at the decorator pattern in Zend Framework applications. This time he takes a step back and shows how to execute them individually.

In the previous installment of this series on Zend_Form decorators, I looked at how you can combine decorators to create complex output. In that write-up, I noted that while you have a ton of flexibility with this approach, it also adds some complexity and overhead. In this article, I will show you how to render decorators individually in order to create custom markup for your form and/or individual elements.

So, instead of registering them with the Zend_Form element, he shows how you can pull out the one decorator (with a getDecorator call) and render it separately. It can be simplified even more with the renderSimpleInput method called on the decorator object. He gives a use case example in defining a form that needs more exact control over the layout.

Matthew Weier O'Phinney has posted the second part of his look at decorators in Zend Framework applications. This time he shows the process behind using multiple decorators to alter the same content pushed through each, one after the other.

You may have noticed in the previous installment that the 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.

He gives the example of a custom form element (as was created in the previous part) and how to split it out into two different parts - one object for the main input element and the other to alter the object and add a label. He mentions overcoming a few issues like appending content instead of overwriting, controlling the order they run in and marking where to add the new content to the content of the object.

Matthew Weier O'Phinney, Zend Framework guru, has posted the simplest Zend_Form decorator hw could come up with:

I've been seeing ranting and general confusion about Zend_Form decorators (as well as the occasional praises), and thought I'd do a mini-series of blog posts showing how they work.

He creates a sample object set to illustrate what the Decorator pattern is - a LockedWindow and StandardWindow that implement a Window interface, a Person object and, as applied to a Zend_Form instance, a My_Decorator_SimpleInput decorator that adds in a new type of input field. The decorator is applied through the configuration array for the Zend_Form_Element in a "decorators" array item.