On a few of my previous projects I found myself creating more form classes than I'd like. And after the 30th one I figured there had to be a better way. I quickly realised that most of the elements within these forms shared similarities to the data type I would use on my database definitions. As I was using Doctrine at the time I figured I could not only drive my database from my mapping definitions, but my forms too.

He shows how post gets into more detail about using the project (configuring caching, other config options).

The project can be found here on github.

In that first part, I implemented the ORM's data access and mapping layers. And as you'll surely recall, the entire implementation process was pretty straightforward and easy to follow. Of course, in its current state the ORM is still far from a fully-functional structure. We need to add some additional components to it, such as a domain model and the classes responsible for handling collections of entities (remember that the ORM relies heavily on the data mapper pattern to do its business properly).

He stays with his "simple blog" example and shows domain models (based on an abstract entity) for Entries, Comments and Authors. His containers extend the Countable, IteratorAggregate and ArrayAccess interfaces to give them some extra abilities.

The Data Mapper pattern is a mechanism for persistence where the application model and the data source have no dependencies between each other. [...] But everytime we talk about the Data Mapper pattern, we assume there is a relational database on the other side of the persistence boundary. We always save objects; we always map them to MySQL or Postgres tables; but it's not mandatory.

He talks about two projects, MongoDb_ODM and CouchDb_ODM, that the Doctrine project is working on to help make working with document-driven databases as simple as the usual ORMs. He includes a brief code snippet showing how the feature will work (hint: a namespace of Document instead of Entity). He lists some of the features - including the usual ORM capabilities, support for collections, cascade of persistence - and where you can get the latest code for it (from github and PEAR

The other day, Klint Finley wrote a very good walkthrough of using the new Multisite functionality of WordPress 3.0. In the comments, a lot of people wanted to know how to use your own Top-Level-Domains. Since I'm doing that now, here's a quick walkthrough/how-to guide.

He uses the WordPress MU Domain Mapping plugin to get the job done and, via screenshots and a little bit of code, shows you how to use the admin panel to easily set up the domains and the sites they should resolve to.

I decided to map all the postcodes onto the UK map where more postcodes for a specific place would create a "lighter" colour. Each postcode has on average about 15 addresses, so in more densely populated areas you have more "postcodes-per-area". Doing this wasn't very difficult and it resulted in the following map.

He walks through the entire process including how, in working with the data, he noticed alignment issues caused by the differing projections the map information service uses (Mercator) versus just mapping to a flat image. Some calculations were made to convert the latitude/longitude to the correct locations and the resulting points were plotted on a cut-out image of the UK.

After I figured out all the maths for this, the only problem that remains that implementing those algorithms in PHP is show-calculating all the positions from the 1.6 million postcode locations takes up to 10 minutes. This is why I am not presenting any code yet. I am planning to implement all the necessary calculations in a PHP extension to speed up the calculations.

In this final chapter of the series, I'll be discussing how to build multi-lingual web pages by combining the functionality brought by the "iptocountry" MySQL table that you learned in previous tutorials and the power of the Code Igniter PHP framework.

Their database tables sort the prodcuts out with the three character country code they're associated with. The IP-to-country tables then help with the translation between the visitor's IP address and which products should be shown.

Welcome to the third part of a series on developing an IP-to-country mapping application with PHP. Made up of four approachable tutorials, this series teaches you how to create a program like this by using a single MySQL lookup table, and shows you how to use this program to enrich your own web sites with geo-location capabilities.

They use the mapping data you pulled from the Webnet77 ip-to-country database (and dropped into the MySQL database) to evaluate where the user is coming from and display product information based on the two letter country code it returns. They throw in a bit about a front controller too, a simpler way to ensure that the user's location code is set for every request.

Building a web site that will be seated on a multi-lingual platform often requires developing an IP-to-country application that permits you to map users' IP addresses to their corresponding countries. [...] This database contains over 82,0000 records and allows you to map more than 3,200,000 IP addresses to their respective countries. This can be really handy for developing different IP-to-country applications with minor efforts.

The review the previous article on making the database and move ahead to create a script that selects - based off the IP range - the country that address could be from.

If you have content in several different languages, your visitors probably speak several different languages as well. Wouldn't it be nice to serve them content from your site in their native language, based on the country from which they hail? You can, even if you're a small company, with an application that tells you a visitor's country based on their IP address. This four-part article series will show you how to build the application and incorporate it into your web site.

They just get things set up in this first part of the series - grabbing the CSV file from the site, creating the MySQL table to import it into and running a script to parse the CSV and push its data into the table.

This tutorial will show you how to create a mashup of three different APIs including integration with Google Maps. This idea came about when I was searching through ProgrammableWeb's API directory for a couple APIs that complimented each other enough that I could use one to provide the other with data. What I came up with will be known as the "Beer Mashup".

They include links to scripts to interface easily with the APIs and the sample code you'll need to query against them. They wrap it up with the HTML for the output page (a map showing "beer hot spots" near your area) and the download of the source and demo to give an example of how it should look.