<xml.lt>

What a great concept has been developed by the guys at Ohloh. It is an open source network that connects people through the software they create and use. If you like developing software and are into social networking as well, this sounds just perfect.
At Ohloh you can find and browse various open-source projects and see who developed them, how they evolved through time, and how much they are estimated to be worth. Ohloh even connects to the CVS/SVN repositories and figures out what languages have been used and who authored what code, line by line! As well as dozens of different kinds of statistics.

We registered our projects as well. They don't look very impressive yet though :)

DIY Framework at Ohloh

DIY Blog at Ohloh

After starting using an ORM and enjoying the benefits it brings, you might soon run into so-called SELECT N+1 problem if you don't use it properly, probably even without noticing it.

SELECT N+1 occurs when you retrieve a collection of objects from database via ORM, and then iterate it accessing the object properties of collection members. For example (we will use Propel):

$posts = PostPeer::doSelect(new Criteria());

foreach ($posts as $post)
{
	$author = $post->getAuthor();
	print $author->getName(); // do something with $author
}

Here we have Post and Author as classes, and each Post has it's own Author (this of course has to be specified as a foreign key in the database schema).
Now, when you access the author of every post in a loop, Propel loads it from the database with a separate SELECT query. And if there were N posts, you get a total of N such queries, plus 1 to load the posts in the first place — thus SELECT N+1.

While such code would work, it is far from optimal, since there is no need to SELECT from database in a loop to get authors of every post. Frequent database queries is one of the biggest hits on backend performance, and SELECT N+1 is causing it but often overlooked. If you are not sure if you have run into this problem, it is easiest to check your database query logs for excessive amounts of alike-looking SELECTs.

The problem is solved using eager fetching, which means that main and related objects are loaded in one go. In other words, when posts are loaded, author for each of them has to be instantiated at the same time, and not later when it is accessed.
The solution is implemented using JOINs and SELECTing data from related tables into one dataset. Processing it into objects (or “populating” objects, in Propel terms) needs little more memory and logic, but that is negligible compared to the overall performance gain. With Propel, it is achieved simply by specifying a different table-specific peer method for loading posts:

$posts = PostPeer::doSelectJoinAuthor(new Criteria());

We are pleased to finally announce the release of the new version 0.3 of our DIY Framework. As promised, it includes new features and solves several issues:

• Complete separation of framework and application classes
• Better integration with Propel
• Support for several applications (and therefore a new directory structure)
• Relative Resource URIs (instead of currently used full ones)
• New sample application
• Extended introduction with UML diagrams

To demonstrate features of the framework, we also release version 0.1 of DIY Blog, an open-source blog/content management engine, on which this website is running, too.

For easier distribution, we have moved our code to SourceForge.

So here come the links:

DIY Framework 0.3

• Introduction
• Project page on SourceForge
• Download page on SourceForge

DIY Blog 0.1

• Introduction
• Project page on SourceForge
• Download page on SourceForge

Happy hacking! Please provide feedback and spread the word :)

PHP 5.2 introduced new DateTime and DateTimeZone classes, which obsolete the datetime functions. They offer a convenient way to store dates and time as objects, instead of strings or integers. Classes also have a better time zone support as well as support for dates outside of the Unix epoch.
But the API, while useful, is rather over-simplified and under-documentented. Here is a good introduction to the API with lots of examples: Looking at PHP5’s DateTime and DateTimeZone by Laughing Meme.

As some people have already reported, PHP 5.3 has namespace support already submitted to its codebase. This is great news, since PHP was really lacking this feature.

Often you have a situation where many Resources have to share the same properties and/or behavior. For example, all Resources in a backend administration application should deny access to users that are not logged on.
A nice and simple solution is to create a parent Resource for the whole application and let all the specific backend Resources to inherit it.

Here is an example. BackEndResource is a general Resource for the whole backend application:

class BackEndResource extends BaseBackEndResource
{
	public function doGet(Request $request, Response $response)
	{
		$view = parent::doGet($request, $response);

		if ($request->getSession()->getAttribute("user") instanceof GuestUser) $view = new ForbiddenView($this);

		return $view;
	}
}

Other backend Resources inherit it:

class AdminResource extends BackEndResource
{
	public function doGet(Request $request, Response $response)
	{
		$view = null;
		$parent = parent::doGet($request, $response);

		if ($parent != null) $view = $parent;
		else $view = new AdminView($this);

		return $view;
	}
}

If a user is accessing AdminResource or any other backend Resource and is not logged on (i. e. user object in the session is an instance of GuestUser), ForbiddenView is displayed with an appropriate message. Otherwise, AdminView is displayed as normally.
In such a way a single line of code allows you to control access to the whole application.

We were looking for a simple open-source PHP profiler, without any fancy IDEs like Zend bundled together. After a little search, we found one: Xdebug, debugger and profiler tool for PHP. It installs as a PHP extension. When you execute your scripts, it simply writes debug information into a file. You can later open and analyze it with a special viewer: KCachegrind for Linux or WinCacheGrind for Windows.

We came across a great read by Ch. Bizer, R. Cyganiak, T. Heath: How to Publish Linked Data on the Web. In a nice and simple manner it describes the basic things you need to know before implementing some practical Semantic Web applications. The abstract goes like this:

This document provides a tutorial on how to publish Linked Data on the Web. After a general overview of the concept of Linked Data, we describe several practical recipes for publishing information as Linked Data on the Web.

We encoutered an apparently 6-year-old bug in Apache, which might as well be a security feature: it treats escaped (URL-encoded) slashes (which become %2F) as normal slashes / in a URL and returns 404 Not Found if such a URL is requested. It does not even come to PHP.

UPDATE: Fortunately, it seems that it actually is a security feature and there is Apache's AllowEncodedSlashes directive to turn it off. There is also a hack by Frédérick Giasson.

Working with Views, sometimes you need the same kind of objects rendered in different ways, depending on the situation. For example, you might want to be able to display an array of products as a list as well as a table. That means each product item should be rendered either as a list item or as a table row.
As you define templates for product items in XSLT, you need a way to differentiate between the two kinds. Here is where template modes come in handy. You can define templates with the same match but different modes, and choose the mode later when applying them. That is excatly what we need — product item templates with list and table modes:

<xsl:template match="Product" mode="list">
	<li>
		<a href="{@resource}{$query-string}">
			<xsl:value-of select="Title"/> (<xsl:value-of select="@price"/>)
		</a>
	</li>
</xsl:template>

<xsl:template match="Product" mode="table">
	<tr>
		<td>
			<xsl:value-of select="@code"/>
		</td>
		<td>
			<a href="{@resource}{$query-string}">
				<xsl:value-of select="Title"/>
			</a>
		</td>
		<td>
			<xsl:value-of select="@price"/>
		</td>
	</tr>
</xsl:template>

They can be applied as follows:

<ul>
	<xsl:apply-templates select="/Products/Product" mode="list"/>
</ul>

<tbody>
	<xsl:apply-templates select="/Products/Product" mode="table"/>
</tbody>