In this new post to his blog Jani Hartikainen looks at implementing the Data Access Object pattern in your PHP applications.

The advantage of this is that you can easily implement different methods to persist objects without having to rewrite parts of your code. I'm again going to use the programming language quiz game I wrote as an example. Since I initially wrote it to use Doctrine ORM directly, and both the old and new code are available, you can easily see how the code was improved.

He starts off with a look at the pattern itself (including a diagram of how an example would work with Doctrine) followed by the creation of the models for his Questions example. Add in the factory to create an instance and an exmaple of it in action and you're there.

Continuing on his his series looking at improvements in the upcoming PHP 5.3 release, Johannes Schluter uses this new post to look at some of the new data structures their update will have to offers in the Standard PHP Library.

In the programming world there are quite a few well understood and explored data structures. Which are commonly used in tons of applications, still the only things PHP offered till 5.3 in regards to structuring data were arrays (more precise: hash tables) and objects. So people had to either abuse them for other structures or implement the structures themselves on top of these. Thanks to Etienne things now are changing and PHP's Standard PHP Library (SPL) extension will offer quite a few standard implementations of data structures.

These new data structures are SplDoublyLinkedList, SplStack, SplQueue/SplPirorityQueue, SplHeap/SplMinHeap/SplMaxHeap and SplFixedArray. He explains a bit of what they are and more detail on one specifically - SplFixedArray.

To help alleviate some recent complaints about the pseudo-random nature of the random functions in PHP, Scott MacVicar has proposed an alternate solution:

With all these potential different ways to get some pseudo random data it would be hard to do this in native PHP. Now we could do this in C and implement all the code ourselves but why risk implementing our own random functions and potentially making a mistake? The answer is OpenSSL, we already have an OpenSSL module and obviously they have some random functionality built in for when you go to generate SSL certificates.

You can make a call to the openssl_random_pseudo_bytes (in PHP 5.3) to grab the number of bytes you need and pass in a "strong" value to get a more cryptographically secure value.

This new post to Rudi's blog shows how, with the help of an external class you can use PHP to grab information from a torrent file.

To use this code you first need to include a file with the benc, bdec and hex2bin functions. To get the torrent data (like the announce url, the files etc) it is enough if we decode the content of the torrent. On the other hand, if we want to read the number of seeds, leechs and downloads, we must encode the info part of the torrent, encrypt it with the sha1 function and convert the result to lowercase.

He includes the code to make the decoding/encryption of the results a copy and paste away (once you have these functions to work from). He's even provided an example using the code that gets the information from a torrent on the Pirate Bay website.

DevShed continues their look at custom exception handling in PHP5 application with this third part of their series, a look at handling exceptions from MySQL calls.

Having already introduced you to the main subject of this article series, it's time to summarize the topics that were discussed in the last article, in case you haven't read it yet. In that particular tutorial I explained how to implement a fully-functional customized exception system with PHP 5, which came in handy for handling a number of specific exceptions thrown by a basic MySQL abstraction class.

They create a custom MySQL exception class that sits on top of their MySQL abstraction layer (and Result handling class) and catches exceptions thrown from sample queries.

This new tutorial from the Zend Developer Zone (by Vikram Vaswani) looks at getting data objects set up between PHP and the DB_OO2 package.

Data objects, which provide an API for accessing and manipulating database tables, are one such tool. There are a number of implementations for data objects in PHP, most notably the popular PEAR DB_DataObject package. This tutorial focuses on one such implementation, the DB_OO2 package, showing you how it can significantly reduce your coding time when working with database tables.

The DB_OO2 package (PEAR) lets you set up references to your database tables as objects and interface with them by setting properties and calling standardized functions. Many of the PHP frameworks out there let you do this same sort of thing, but those are built in - this method lets you use the package wherever.

In a recent post to his blog Daniel Cousineau shows a method for correctly outputting CSV data in push down to the client browser as a method of export.

Nearly every application you could write in for the business sphere in PHP probably requires some sort of data export, most likely in the CSV format. The easiest way to provide a downloadable file is by altering the headers and echo'ing the file content.

His method sets the headers for the CSV file type then pushes the content out (contained in an array) via the fputcsv function. He wraps it all in a function near the end for simple cut and paste.

On Devollo.com the first part of a series looking at something every PHP developer (or any other for that matter) should include in their application - data filtering.

Filtering data. We all have to do it. Most, if not all of us, despise doing it. However, unbeknown to most are PHP's filter_* functions, that allow us to do all sorts of filtering and validation. Using PHP's filter_* functions, we can validate and sanitize data types, URLs, e-mail addresses, IP addresses, strip bad characters, and more, all with relative ease. This is part one of two, covering filter_var() and the different constants and flags that can be set.

This method, using the filter extension, takes a lot of the work out of making sure that user-submitted data is what it should be. They include examples of how to filter numeric types, URLs, email addresses and how to sanitize the data to be sure there's no cross-site scripting or SQL injections to be found. This is a great reference if you're looking to get started with the filter extension.

On his blog, Roshan Bhattarai shares a few tips on keeping your application safe by filtering user-submitted data.

Yesterday, I saw one of my friend was working on the the contact form and was filtering the user input data(posted variables) individually. He was using a function in PHP to filter the input and using tedious approach while calling the filtering function for each variables with coding each of them in single line . Today, I'm going to show you how can you filter the posted variables easily using callback function in PHP.

He shows how to create a filter_data function (for removing HTML embedded in the data) and how to implement it around your data. It could be extended pretty easily to do more than one filtering method to protect your information even more.

For a recent REST web service project, Lorna Mitchell had to put together a server for the remote clients to use. She started with a GET request then moved to handling a POST request then to a PUT request - that's where the difficulty came in:

PHP doesn't have a built-in way to do this, and at first I was a little confused as to how I could reach this information. It turns out that this can be read from the incoming stream to PHP, php://input.

Pulling from that stream gave her the raw data she needed (nicely urlencoded too) that she could parse out and use. She includes a simple example that has a check for the REQUEST_TYPE in the _SERVER superglobal to see how the request should be handled (PUT versus GET).