<xml.lt>

With the completion of the application we are currently working on, we are also planning to release a new version of the DIY Framework. It should include new features and solve 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 — a simple yet functional blog engine
• Extended introduction with UML diagrams

Many Web frameworks these days (e. g. Symfony, which is one of the more popular ones) are listing URL routing (sometimes also called mapping) as an important feature. Routing basically rewrites URLs with parameters into more user-friendly URLs, most likely hierarchical ones. For example:

http://www.example.com/index.php?category=2&page_id=3&action=view

after routing might become:

http://www.example.com/news/today

Symfony uses a special routing.yml configuration file, a PHP layer and also Apache's URL rewriting behind it to implement routing.

With the DIY Framework, URL routing as in Symfony is simply not necessary. It works another way:

• No physical .php files (except for one front controller for each application) are directly accessed from the web, so there is no need to hide them. All the code has to belong to classes and there can only be a single entry and output point in the application. Moreover, URLs are completely independent from Resources and the code that handles them.
• No action parameters are needed, since there is no concept of some abstract action. Resources are RESTful and simply implement HTTP methods.
• No ID parameters are needed to identify pages or Model objects (e. g. products or users) since these relationships are already known at the PHP and database levels. Model tables and classes are related to the appropriate Resources as defined in Propel's schema.xml.

That said, there is no need for some proprietary routing configuration and also no performance cost from the routing layer. Moreover, there are by design no potential security breaches such as passing wrong IDs. Symfony instead tries to cover them with URL routing.

Today we were checking if some of the views in an application are setting the right HTTP status codes and response headers. In case of a notFound view, the status code was 404 as expected, but there was something strange about the headers:

HTTP/1.1 404 Not Found
Date:		Tue, 28 Aug 2007 21:25:51 GMT
Server:		Apache/2.2.4 (Win32) PHP/5.2.2
X-Powered-By:	PHP/5.2.2
Content-Length:	2355
Keep-Alive:	timeout=5, max=100
Connection:	Keep-Alive
Content-Type:	application/xhtml+xml; charset=UTF-8
X-Pad:		avoid browser bug

Notice the unexpected X-Pad header. We guess it is set by Apache, but does anyone have an idea what for?

In the past few years, many developers and companies are moving to ASP.NET from other platforms, and I can't stop wondering why. From my personal experience, ASP.NET is clumsy, and while it is possible to build big and useful applications with it, it is achieved in many situations by going against the the very nature of the Web, without the regular developer realizing it.

Here is a few points that bother me:

• As with all .NET, you're stuck with Windows. There are open-source alternatives such as Mono, but they are not always appropriate.
• You're stuck with an IDE. ASP.NET likes to generate huge amounts of code, and it would be hard to write or edit it by hand
• With drag-and-drop design and default controls, your HTML skills become nearly worthless, and you are never sure about the quality of the code they generate. There are limited ways to tune them, and it becomes quite a problem when the page has to be XHTML or CSS valid. Moreover, you cannot easily change the design of a whole site as with stylesheets.
• I don't know if that is still the case, but I read that ASP.NET automatically generates different HTML code for different browsers. Some see it as an advantage, I however see it as an intrusion into my application design, since I want to know what's happening behind the scenes and control my code completely.
• Parts of the functionality are tied to a specific client, namely Internet Explorer browser
• Postbacks and HTTP POST method are way overused. Seems like GET is ignored, not to mention PUT or DELETE. REST principles are completely broken.
• Control flow is very non-intuitive, especially for those who have worked closer to HTTP level. Postbacks are by default submitted to the current URL, which is not always desired. Putting data into a session and then redirecting looks like a normal way to program in ASP.NET, instead of simply submitting the data to the right location or encoding it into URLs.
• From a first sight, it seems like ASP.NET is quite successful in imitating the event-driven programming model on the Web in a similar fashion as in Windows applications. However, that way it has to go around the request-response nature of HTTP and use nasty workarounds such as viewstates.

To conclude, drag-and-drop and events might be great for desktop applications, but it is not the case with Web development. The core technologies are just too different. If you come from Windows and like drag-and-drop design, you might as well like ASP.NET. However, if you want to know how exactly your application is functioning, to control the code it produces and to make sure it is simple and elegant yet valid, ASP.NET is not for you. Tunning it to the desired result would require more resources than completing the application on a different platform. And it does not mean you have to be producing spaghetti code — there are better ways to separate concerns than in ASP.NET.

Sometimes there is a need to serialize XML into a string. For example, if you're working with XML or XHTML that is created or edited in a web form. With XSLT as a template engine, you cannot simply dump the XML with <xsl:copy-of> as the contents of <textarea> in the editing page — it would result in that page having an embedded piece of custom XML, which is invalid and not what you expect. With <xsl:value-of> you would get the string contents only, without any markup.
Instead, XML has to be serialized (escaped) into a regular string before outputting it. That is where the XML-to-string converter from Evan Lenz comes handy. After including it in your stylesheet, it can be called in the web form scenario like this:

<textarea id="content" name="content" rows="10" cols="90">
	<xsl:call-template name="xml-to-string">
		<xsl:with-param name="node-set" select="Doc/NodeToEdit"/>
	</xsl:call-template>
</textarea>

Version 5 introduced several features in PHP that bring the language closer to full-featured object-oriented languages such as Java. We'll try to cover a few of them, those that we use in our framework.

One of the features is type hinting. Functions are now able to force parameters to be objects or arrays, for example:

public function doPost(Request $request, Response $response)

private static function serializeArray(Array $array)

That makes the code more readable and predictable. There is no way though to specify primitive types such as integers or strings.

The feature would be useful together with method overloading for creating polymorphic methods or constructors with different parameter types. However, PHP 5 does not support method overloading as such, but is possible to achieve in it's own special way via the magic __call method.