Continuing on from the first part of their series, DevShed has posted part two of their "Building an ORM in PHP" series. This latest tutorial focuses on domain modeling (and collection handling).

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.

PHPMaster.com has posted its third part of its "Localizing PHP Applications 'The Right Way'" series. In this third part you'll learn more about locales and message domain switching.

In Part 2 you gained more insight into using the gettext library by learning the most important functions of the extension. In this part you'll learn how to best use a fallback locale, switch between locales, and override the currently selected message domain.

They show you how to set up the directory structure to handle a fallback locale, a choice to use when the system can't determine which to use. By using a default, you also avoid having the system translate from the default language to...the default language (like "English" to "English"). Included are also the code bits you'll need to switch between locales (just using a different domain) and using the dgettext function to specify a different domain than the selected one.

On the Ibuildings techPortal today there's a new post from Robert Raszczynski about domain modeling and how a good knowledge of it can help your application's architecture.

Architectural and design patterns help software architects to break systems in to smaller, more maintainable sections organised by their functionality and usage. [...] There are three major layers in software architecture: presentation, domain and data source. [...] Now that we know what types of layers we can find in software architecture, let's have a look at how we can organize domain logic and data sources layers.

He looks at three patterns that can help organize your domain logic - a transactional script (one file that does one thing), a table module (logic lives in the tables) and his focus, the domain model. He shows (via a graph) how the domain logic approach can cut through some of the effort it could take to improve on the other two. He gives a two suggestions of how to access the data in your domain layer - a Gateway or a Data Mapper. To reinforce the ideas he's presented, he includes some code snippets of a basic domain model for a Store, Customer and Product and uses them in both Gateway and Data Mapper examples.

Martin Aarhof has put together an handy tool for Zend Framework applications that creates the async javascript analytic code recommended by Google to provide tracking information back to Analytics.

It supports: browser Settings Detection, campaign Duration, campaign Fields (custom), cross-domain linking and last but not least Ecommerce tracking.

The configuration lets you set the various keys for your Analytics accounts, the domain name for it to live under, browser detection settings and various other settings for campaign configuration and domain setup. You can find the full code on his github account ready to download or clone.

Cal Evans has posted the eighth tip in his six-tip series (but who's counting) about how a client can coordinate better with a developer and make a better relationship for the project. In this new tip, he suggests that the client "own it".

No, I'm not talking about own it as in Point 7 - "Do your part", I mean make sure that at the end of the project, you own the project, not your developer.

He mentions two of the aspects you, the client, will need to worry about once the last line of bug free code has been committed and delivered. Be sure that you own the domain name for the project and have a clear understanding of any intellectual property concerns that might come up (what codebase is it built on, who owns the code - client or developer, etc).

On CodeForest.net there's a new tutorial showing you how to set up a WAMP (Windows/Apache/MySQL/PHP) server that uses multiple virtual hosts.

Virtual hosting is a method for hosting multiple domain names on a computer using a single IP address. This allows one machine to share its resources, such as memory and processor cycles, to use its resources more efficiently. This is often found on shared hosting servers. [...] We can use Virtual hosts on Windows to deal with this problem. As I am using WAMP server for development, this tutorial will explain how to do it in WAMP, but other products are very similar, so you want have problems porting this.

They walk you through each step of the process, including any settings or configuration files changes you'll need to make along the way. Their configuration helps you set it up for your localhost, but it can be pretty easily moved over to a live server just by changing a few IP addresses.

Ilia Alshanetsky has posted the next article in his "domains and PHP" series - a new slicing of the data showing the ISP popularity by domain counts, a breakdown of the top 25 with over 100,000 domains to their credit.

The results are pretty interesting, and it clearly shows that a small number of ISPs are definitely doing something right, which is causing many consumers to vote with their dollars in those ISPs favor. As usual the information is shown in graph form, to filter down the data to just the large providers I've set a minimum at 100,000 domains, leaving me with just 122 ISPs. The image [below] shows the break-down of the Top 25.

He's created a pie graph that breaks down the ISP list with GoDaddy once again coming in top of the list and The Planet coming in second. The numbers behind the graph are also included with other things like IP, country, region and city for each. He also mentions other major breakdowns like the top ranking IP addresses and the total number of around 80,000 IPs that have over 100 domains resolving to them.

Ilia Alshanetsky has posted the next set of results from his domains-running-PHP research he's been doing. In this latest post he looks at the domain distribution by city mostly falling in the US, Europe and China.

I am making available two additional geographic chats that breakdown the domain distribution by top world cities. The first chart a preview of which can been below (click to see full, browse-able/zoomable version) shows the Top 150 cities, by domain distribution. These cities represent a total 91.3% of some 102 million domains that could be resolved to a city level.

The top ranking city falls in the US in Scottsdale, Arizona (because of the large domain provider GoDaddy being based there) with the second place spot going to San Francisco, California. He's created both a interactive map you can use to see the numbers for different parts of the world and a concentration view of the same results making it a bit easier to digest.

Ilia Alshanetsky has started to gather more and more information about PHP usage on the web as a whole (that was started here) and has been extended with some additional statistics he's done on the location of the domains he's collected.

The first step of the process has been resolving all of these domains, which is now complete. The next step is fetching the server information, which began, but will take some time to finish. However, even from the domain revolving data there is a lot of useful data to be gleamed, which is what I am now publishing. My first focus was on the world-wide distribution on these TLDs, which at least for me held a few surprises.

He includes a few graphs of the results he's found showing things like:

• The US has the most domains hosted followed with less than half by Germany
• The overwhelming majority of the PHP domains are in the .com area
• In the US, the state with the highest number of PHP-powered domains was Arizona with Clifornia coming in second

If you'd like something more interactive, he's also come up with a clickable world map of the results for you to click around on.

In a new post to his blog Evert Pot looks at internationalized domain names and where they could cause issues some of the current validation in PHP applications.

Since may 11 TLD's (top-level domain names) have been added. In order for this to work successfully, a lot of applications will have to be fixed. Many email-validation scripts might use [a regular expression] approach [to match most address formats].

Unfortunately, this approach will only continue to work with the normal ASCII-based domain names. He includes a list of several that could break it including ones in Chinese, Korean, Persian, Russian and Arabic. He recommends a very liberal regular expression (one that allows for "punycode" strings) to check the email, find the record and try to find an MX record on that domain.