Often referenced by a few other fancy names, the substitute is generically called a virtual proxy, a sort of stand-in that exploits the neatness of Polymorphism and interacts with the actual domain objects. Proxies aren't new to PHP. Doctrine and Zend Framework 2.x make use of them, although with different aims. On behalf of a didactic cause, however, it would be pretty instructive to implement some custom proxy classes and use them for lazy-loading a few basic aggregates from the database, this way illustrating how virtual proxies do their stuff under the hood.

He starts off by setting up a domain model for a "Post" and "Author" - a typical blog example.Based on the definition of these classes, he creates a mapper class to generate Author objects and an "AuthorProxy" class that uses a "loadAuthor" method to only load in the author's details when a property is requested. He gives a bit more code showing it in action and the difference between using the normal Author and AuthorProxy class.

Debugging locally is a nice improvement to have no debugger at all, but in many situations there is the need to debug on production server, where the application is running on the web. There are different reasons for that, but the most important one for me is, that my local environment / installation is different from the one i have on servers in data center and bugs can be related to the environment.

He walks you through the installation and server-side configuration of XDebug first then shows how to install the Komodo Remote Debugging Client to help with multi-user debugging setups. He mentions setting up the debugging on the client/IDE side, but there's no specific instructions for any particular IDE - just how it works overall.

Unless you're new to this web development lark, you'll know the 'X' in 'AJAX' stands for XML - eXtensible Markup Language. But you're probably not using XML. If you are, you'd probably prefer not to. All the cool kids are using JSON or JSON-P: it has a smaller payload, is easier to use and faster to process. [...] Fortunately, there are a couple of solutions which allow you to retain the benefits of XML data interchange but provide the ease of JSON in JavaScript. In this article, we're going to create an XML to JSON proxy server in PHP.

Of course, this will only work with well-formatted XML documents, but it's a quick little hack that pulls in the XML data with a curl request and parses it via SimpleXML and uses json_encode to push it back out as JSON.

The outcome is this little library making it much easier to generate a proxy of your system under test (SUT). Another thought on this library was, that it should be very easy to use if you know the way to mock classes and methods in PHPUnit. Proxy-object has almost the same API, but does not change the behavior of the proxied class/method. The only purpose is to expose hidden methods and members.

The scripts, found on github, give you a simple way to define a proxy over a given class' functionality and define methods/member variables to be exposed. He includes two code examples, one of each type. There's also an example of making the proxy object without calling the constructor, useful in certain cases when the initialization of the object doesn't need to happen.

You can also find out more about the usage of this tool in this new post to Bastian's blog.

Of the other patterns mentioned, the one closest to the Proxy is the Decorator. In the case of a Decorator, the focus is on adding functionality to an existing object -- for instance, adding methods, processing input before delegating to the target object, or filtering the return of a method from a target object.

Proxies stand in for objects and have several benefits for your application that may or may not need all of the overhead a full object could cause. Matthew focuses on one benefit in particular - consuming and controlling access to another object. He sets up a problem of wanting to use properties/methods on objects that aren't exposed directly (like a protected method). His solution is a proxy layer class on top of the original object. He includes a few "gotchas" to look out for when using this technique including overwriting all necessary methods and copying over all of the needed properties.

I like taking pictures, and I usually take a GPS so that I can place them on a map on my Flickr page. On my last excursion however, the battery of my GPS had died, so I did not have location information available to store in my pictures' EXIF headers. Flickr can use the EXIF headers to then show the images on the map. Because I did not have the location information to automatically place my pictures on the map, I wanted to do that by hand.

His script (as used by a local Squid proxy) supports two different versions of the mapping - one for Yahoo! Maps and the other for OpenStreetMaps'. You can see the end result here - a set of Flickr images with a map in the background.

In reading over the chat room log for my recent webcast, Zend Framework: Piece by Piece I noticed a question from my buddy Elazar [Matthew Turland] about Zend_Cache_Frontend_Class. Thinking I had made a mistake, I reviewed the materials and the Zend_Cache_Frontend_Class documentation page so that I could do a quick update. The answer wasn't nearly as simple as I thought.

He notes that it's not a proxy and caching tool for objects and their data as he originally stated. In fact, when you call it directl, it does work this way. When you create it in a cache object, though, the resulting object isn't created correctly. To solve the issue, he gives two ways to properly use the Zend_Cache_Frontent_Class component - an easy way and a hard way. In one you make the class first and pass it in and, in the other, a suggestion for integrated model caching.

As author of Xdebug, people ask me often the question how to handle the case in teams when there is one development server and multiple developers working on the same project on that server. [...] Now, in order to solve the above mentioned issue, you will need to run a DBGp proxy. DBGp is the protocol, designed by ActiveState and myself to facilitate communication between an IDE and PHP+Xdebug.

He walks you through the setup process - how to point XDebug to the correct location and how to configure the proxy to handle the multiple incoming requests and route the debug information back to the correct client.

I haven't studied how other engines do it, but here's how I do it. First off, some benefits to sharing the CMS across separate sites: reduced resource usage, easier upgrades, easier bug-fixing. Convinced yet? Of course you are. Here's how you do it.

There's four steps to his process:

• Separate out the site-specific files from one another
• Serve all site-specific files out through a "proxy" script that can intelligently grab the needed ones based on the site
• Override the default configuration at request time (forcing it to use that "proxy" script)
• Create that proxy file that the web server can funnel the requests through (his example is included).

So I have been working on a little class to run a reverse proxy from PHP using cURL. I have extended this class for my own purposes (single-sign-on) to handle some special request parameters, but here it is. It has some warts, but it's a good starting point.

He creates the ProxyHandler class in the first post and in the second updates the script to pass a more correct version of the headers to the proxy server to get a better response back.