I think some people may overlook the importance/usefulness of the decorator pattern since all you’re doing in the examples could be accomplished by just concatenating P and /P around the getData() wherever it is you were going to display it.

I find the decorator pattern is best for when you have a lot of parts to the data that need a lot of manipulation of their values and a lot of html but not so much html that it warrants a full page/template/view.

For example in my (poorly written) real estate site I have an object that represents a property for sale in the listings table of the DB. All 126 fields of the property record!

When it’s time to show info about the property to a visitor I only need to show them about a dozen fields. But most of those fields need to be manipulated. I need to ucfirst() the property status text, convert the price to Euros/Pounds/USD/BSD, attach the http://www.site.com/listings/… onto the permalink text of the listing, convert 3.5 into “3 1/2 Bath”, convert the square feet values into Acres if they are over 1 acres in size and lots of other stuff. Also all these fields had to be wrapped in html tags and ids and css classes etc.

At first I had all that stuff as part of the code that happens _before_ the data is saved to the database. Then other clients came along who wanted the same system (but different) and I realized a lot of those manipulations were only relevant to the site visitors. So then I put those instructions in the main class file as $listing->displayOverview() method.

But then some more clients came along who wanted something other than the default set of info in the default format. Some clients wanted the category value to link to a search results page of everything in that category. Some wanted the neighbourhood value to do the same. Some didn’t want the category or neighbourhood value to be shown. Sure I could have just use css to hide the neighbourhood span but some high end clients don’t want anyone to know where their house is located so the neighbourhood/address values weren’t allowed to be anywhere in the markup. They had to be taken out at the code level.

It unfortunately took a looong time and a lot of clients on this system to realize I needed to take this segment of my code and turn it into a custom decorator for each client that needed one.

Before that realization, at one point I had a site identifier variable and a ton of IF statements strewn throughout the code that made it a nightmare to read!

For another good example of decorator usage see this Zend Framework Zend_Form screencast (requires having a zend.com account).

I’m hoping it’s the same issue I had with Zend Studio 6. It seems Zend hates XDebug or something. People say PDT (upon which zend studio is based) works fine with XDebug but for some reason the Zend people chose to hard-code the XDebug option OUT of the Zend studio preferences.

After a lot of searching I finally tracked down remnants of the instructions that got XDebug to work in my old Zend Studio 6. I’ll repeat them here if they work for 7.

distreff – see dtaylor7′s post above yours for steps on how to get XDebug enabled again. Having a Mac, I started with the steps I’d worked out for PDT (http://www.makovec.net/software/39-software/55-eclipse-pdt-with-debug-on-leopard.html), then did the following from Terminal.app:

cd /Applications/Zend/Zend\ Studio\ for\ Eclipse\ -\ 6.0.1/plugins
mkdir disabled
mv com.zend.php.debug.* disabled
/Applications/Zend/Zend\ Studio\ for\ Eclipse\ -\ 6.0.1/ZendStudio.app/Contents/MacOS/ZendStudio -clean

After you’ve done all that from the command line, your XDebug options will be back. You can then quit out and go back to loading up ZSE from the desktop.

– http://devzone.zend.com/article/2930
– http://devzone.zend.com/member/5810-dmakovec

The specific commands that worked for me:

:: cd /Applications
:: cd Zend
:: cd Zend\ Studio\ -\ 7.0.0
:: cd plugins
:: mkdir disabled
:: mv com.zend.php.debug.* disabled
:: cd ..
:: cd ZendStudio.app/Contents/MacOS/
:: ./ZendStudio -clean