In this recent post to the Duckout blog, they show you how to hook your PHP-based (and database driven) application into the Google Charting API for chart/graph generation.

I think, whenever we see a chart in a magazine, in books or applications our brain say's to us Yeepie!!! Don't read these stupid texts or tables! Just look at the green or yellow line and hope that they are above the other lines or hope that your opinion is the biggest part of the pie¯. This saves us a lot of work and in my opinion we should concentrate on drawing beautiful colorized pie charts, instead of writing long boring articles. But the question is: ¯How do I draw these beautiful colorized pie charts? The simple answer is: you don't have to, because google will draw them for you and you just have to tell them what to draw via the google charts api.

The sample application is a "breakfast rating" tool that logs the results to a MySQL database via PDO calls. The results are then extracted and formated as JSON to be compatible with the Google Charts API data handling. Some sample Javascript is included showing how to call the Charts API with your data and get back a simple line graphing of the data from the database. You can see the application in action here for reference.

Jason Fox has a recent post to his site about using "Accept" headers in Zend Framework 2 apps to set the format of the return data from a request.

In this article I detail the process by which you can set up your controller actions in Zend Framework 2 to return either the default HTML, or JSON data depending on the "Accept Header" in the request. It incorporates changes related to a security update added since this very helpful article was written, and expands on some of the intricacies of making your web layer objects better "json providers."

His example uses a "ViewJsonStrategy" and the criteria to look for to determine which version to respond with (HTML or JSON) - the Accept header. It uses the JSON encoder/decoder instead of the built-in PHP one to he could use the included "toJson" method to customize the output of the JSON instead of just returning everything.

Michael Nitschinger has written up a new post comparing a few different methods for serializing or translating objects to store them in a cache. In it, he compares the PHP serializer, the igbinary extension and translation to JSON.

Storing PHP objects (or simpler data types like arrays) in caches always requires some kind of transformation. You need a way of encoding/decoding data so that it can be stored and loaded properly. In most languages, this process is known as object serialization. PHP provides a mechanism for this out of the box, but in this article we'll also look at igbinary as a drop-in replacement for the default serializer. We also compare the results to object transcoding based on JSON, which is not really an object serialization mechanism but commonly used as a data chache structure which has its own benefits and drawbacks.

He goes through each of the three technologies and includes a snippet of code showing how they'd work in object translation. He also talks about things like the size of the result and the performance of each when the results are looped over. Based on the results of some of his "microbenchmarking" of each of the methods, igbinary came out on top, even faster than PHP's own serialize/unserialize.

Bob Majdak has a quick new post to his site showing you how to log messages to Apache using a JSON format instead of the usual single-line information.

So this past week I have been doing a lot of logging, parsing, and graphing. I was sitting there wondering what I could do to make the Apache access logs easier to work with. Then it hit me, a brilliant stroke of win: why not format it in JSON? Then in my log parser I could just json_decode it! As far as I know there are no tricks to make Apache do this for you, so really all we have to do is define a custom log format that happens to look like JSON.

He includes the "LogFormat" line you'll need to add to your Apache configuration to make it log the JSON and a bit of PHP to help you pull in the file's contents and parse each line.

If you're a speaker (or even if you're not and just want to play with the API) and have information on Joind.in, Lorna Mitchell has a quick way you can pull you information from the site into an easy to use format.

I've recently been thinking that I should also do a better job of linking through to the various talks I'm giving/have given - and at around the same time I was contacted by the good folk at mojoLive about integrating against joind.in. To cut a long story short, the joind.in API now has the functionality for users to retrieve their list of talks!

Her example just uses a file_get_contents to pull the data from the remote URL in a JSON format. You don't need to be logged in to get to the talk information, though, so you won't need to bother with OAuth for this one. A snippet to loop through the results is also included.

Michael Nitschinger has a new post to his blog about JSON handling in PHP and how to work with it "like a boss".

There are already lots of tutorials out there on handling JSON with PHP, but most of them don't go much deeper than throwing an array against json_encode and hoping for the best. This article aims to be a solid introduction into JSON and how to handle it correctly in combination with PHP. Also, readers who don't use PHP as their programming language can benefit from the first part that acts as a general overview on JSON.

He starts with an introduction to JSON - what it is and what a typical structure looks like. He moves into how to encode JSON in PHP using json_encode, showing teh result of encoding things like arrays, strings and associative arrays. He also includes a bit on translating an object and the resulting JSON string. He mentions the options bitmasks, shows how to decode JSON you're given and talks about error handling and testing of the results.

In a previous post Rob Allen showed how to return JSON data from a controller in a Zend Framework 2 application. In this new post he shows how to use the "Accepts" header from the client to do the same thing.

Following yesterday's article on returning JSON from a ZF2 controller action, Lukas suggested that I should also demonstrate how to use the Accept header to get JSON. So this is how you do it!

You'll need to create the JsonStrategy first, then you can return the ViewModel from the controller. If all goes well, you should see the sample HTML page rendered in a browser and JSON output when requested with the right "Accept" header (he uses curl in his example).

In a new post to his blog Rob Allen shows how you can return JSON data directly back from a controller in a Zend Framework 2 application.

The new view layer in Zend Framework 2 can be set up to return JSON rather than rendered HTML relatively easily. [...] Firstly we need to set up the view's JsonStrategy to check to a situation when returning JSON is required and then to render out JSON for us.

This "JsonStrategy" does some of the hard work for you - detecting when the client is requesting a JSON response and looking at the data coming into the view to see if it's JSON. He shows how to implement it in a sample module using the "onBootstrap" module and how to force a return of the JsonModel even when JSON isn't requested (useful for a consistent interface).

In this recent post to his blog, Konr Ness has benchmarked the components that the Zend Framework uses to read in different types of configuration files - JSON, native PHP arrays, INI, XML and YAML files.

If you application relies on parsing one or several config files each time it is bootstrapped it is important that you select a file format that is fast to parse. But you also want to select a config file format that is easy for a human to read and edit. In a recent application I am building I also had the need to write modifications to config files, so I also benchmarked the Zend_Config_Writer components.

He includes both the sample configuration INI file and the benchmarking script he used to measure the results (all configurations were read from external files, even the native PHP option). His results were pretty predictable (with the exception of YAML reading) with the standard INI file coming in second to the native PHP arrays, but having the advantage of being more readable.

In the first two posts of his "features new to PHP 5.4" series Slawek Lukasiewicz has posted about two things that weren't mentioned very often in most of the 5.4 hit lists - improvements to the JSON extension and the header_register_callback method.

About the JSON extension improvements:

By default, when we pass object to json_encode function, it will return JSON representation of object public properties. [...] PHP 5.4 introduces JsonSerializable interface with JsonSerialize abstract method. After implementing this method we can independently set values used in JSON representation.

Related to the header_register_callback addition

After looking at new functions introduced in PHP 5.4 we can found one called header_register_callback. Using it, we can register callback which will be called before sending output.

The stable version of PHP 5.4 has officially been released, so get out there and grab it and start using these new features now!