To overcome your skepticism [of an easy to use, flexible view system], in this two-part tutorial I'll show you how to implement from scratch a couple of customizable view handling modules by sinking our teeth into the goodies of the Composite and Decorator patterns.

He starts off by creating a foundation to work from - a basic View class that takes in data, allows for the setting of a template and combines it all together when "render()" is called. He then takes this example and applies the Composite pattern and creates interfaces for the template, container and view, implements them and shows how to attach views to other views. Each of these views is then rendered when the main "render()" method is called and the output is appended.

One of the hardest problems to solve when developing an ORM of any complexity is in deciding how to handle the retrieval of rows that satisfy a many-to-many relationship, also known as a M:N relationship. [...] To model M:N relationships, database developers must get creative. By employing the use of a "3rd party", and by utilizing foreign keys that model a 1:N relationship, database developers can model a M:N relationship.

He looks at the Zend_Db_Table_Row class of the framework and how it works with these junction tables and how it has an issue where it returns the junction table columns too. A fix was released (in 1.10.2) for the framework to work correctly. Unfortunately, this also left those using the method out in the cold. So, Ralph has created his own workaround called a composite rowset. He includes an example snippet to give you an idea of how it works, but you can download the code from his github repository for a closer look.

Today had quite a number of Zend_Form-related questions in #zftalk. Everything from Decorators to Composite Elements, you know - the usual Zend_Form questions. What better way to answering questions than with a blog post and some sample code?

His illustration of decorators shows how to put each of the form elements inside of a "DI" tag to help makes the lives of the frontend developers that much simpler. For the composite elements he shows how to use them to group a set of selects into one object that is then validated through Zend_Date for valid date information. You can grab the code for each of these illustrations from this account on Github

This video should help you build your own composite Zend_Form element. We'll be building a phone element. The phone element will have 3 textboxes, one for geographic location, area code and local code. In the following videos will add a custom cell phone validator and some ajax validation.

You can grab a copy of the source if you'd like to follow along or you can just look around the repository to find the source for this and other great lessons from the site.

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.

A design pattern is a general reusable solution to a recurring design problem in object-oriented systems. Design patterns are essentially blueprints that suggest how to solve a particular set of OO design problems while adhering to OO best good-practices (which I've recounted in my Object Oriented part of this series).

He talks about one of the most popular examples - the Model/View/Controller design pattern that is used in many rapid development frameworks for PHP (including CodeIgniter and the Zend Framework). He also briefly mentions a few others like the composite, singleton and decorator patterns.

Other parts of this series include looks at testing, refactoring and coding standards.

In this post, I offer a brief explanation of the Composite View pattern. It's beyond its scope to show an implementation using the Zend Framework though that's what I'm building up to accomplish in a later blog entry.

He goes through what the design pattern is (including a UML diagram showing it's relations) and how it's commonly used. Following this, he shows a little bit of the code in action that includes the use of an attach() method to include the "child Views" at certain locations.

Back on track, the main problem of a complex View, is that the current Controller is only aware of a subset of its own required Model (data) and the current View. So how do do you get the View to include extra sections - for example, details from Technorati for your blog - which are common to ALL pages?

The framework's documentationComposite View and View Helper combination, to accomplish the "reusable page bits" they need.

Are you a PHP developer who wants to improve your skills in pattern-based programming in PHP? If the answer to this question is a emphatic yes, then you should begin reading this article now! Welcome to the final part of the series "Implementing the composite pattern with PHP 5." Comprised of two instructive tutorials, this series walks you through the basic concepts of this important design pattern, and shows you how to apply it with some educational examples.

They start by defining a simple StringProcessor class as an abstract interface to build from. From there, they create two other classes - the SingleStringProcessor and the MultipleStringProcessor. Each of these takes in either a single file or multiple filenames and spits back out the value of the string and the length of the string.

The composite pattern is one of the less commonly used patterns in PHP 5. Nevertheless, in certain situations, it is very helpful. This article, the first one in a two-part series, will introduce you to the basic concepts of the composite pattern.

The composite pattern allows you to define a single or multiple objects that will have identical behavior - basically behaving the same if there's just one or with the multiple instances. They start with the basics, reaching for one of their standard examples - a file information reader - to illustrate their point. They create the two helper classes it needs to work, one for the single file read and another for the multiple file read. The finish by combining them all together for a file-reading fiesta, showing how to get a one shot info dose as well adding files to the list and grabbing their info all together.