On SitePoint.com today there's a new post from Craig Buckler showing you how to create a simple XML to JSON proxy server in PHP with a SimpleXML object at its heart.

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.

On the Liip blog Bastian Feder has announced the first release of a tool that helps you proxy your objects (overlay them with a layer that exposes properties and methods) following the proxy object design pattern in PHP.

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.

In a new blog post Matthew Weier O'Phinney has taken a look at proxy objects (the Proxy design pattern) and how it differs from some of the other popular patterns.

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.

Derick Rethans has a new post today with a bit of code showing how to combine Flickr and OpenStreetMap and make a mapping tool that plots out the location information for the Flickr images.

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.

Cal Evans has posted an update to comments made during his webcast for php|architect on the Zend Framework:

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.

For most developers, working with XDebug is a simple matter of setting up the extension and getting to work. For larger teams, though, its not quite that easy. The way that XDebug is set up by default, it's no quite conducive to multiuser situations. Derick Rethans is here to help in his latest blog post, though. He describes a method (using a DBGp proxy) to handle splitting things between multiple developers.

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.

Kae Verens has a few tips to help simplify your life with your current content management system by using one code base to run multiple sites.

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

Brian Snugg has two new posts relating to his script for a reverse proxy in PHP5. The first lays the foundation, the second makes some updates to make it a bit more efficient.

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.

A pretty cool project in PHP - Memproxy is a caching proxy "server" that uses memcached for storing the cache. This project uses PHP scripts to handle caching using memcache.

The server uses memcached to store the information and automatically manages things like TTL, custom headers and is "application agnostic" all wrapped up in a small codebase with minimal dependencies.

Brian Moon has announced the release of the latest version of his memproxy tool that uses memcache to create a "server" to save the proxy information.

I put server in quotes because it is really just a PHP script that handles the caching and talking to the application servers. Apache and other HTTP servers already do a good job talking HTTP to a vast myriad of clients. I did not see any reason to reinvent the wheel.

Features of this new version include a TTL for the cached data, minimal dependencies for the application to use and a small code base consisting of two files. It also handles HTTP 1.1 requests, is transparent and applows pages to dynamically be specifically added and removed from the cache.

You can download this latest version from the project's page on the Google Code website.