<xml.lt>

While working on database query optimizations with Propel, we got an idea to check how our website compares with others in terms of loading speed.
According to Website Speed Test tool, it is doing pretty well (even without running the latest version of the DIY Framework): the front page currently is 20.54 KB and takes 0.44 seconds to load, resulting in average 0.02 seconds per KB.
How does your website compare? Server location of course makes a difference. According to VisualRoute, seems like our is located in Dallas, TX, USA.

Version 1.3 of Propel (a popular and very useful ORM tool) is in the works, currently released as beta. We believe it should bring substantial improvements and we are going to switch to it sooner or later. Upgrading will involve several things:

1. New PHP minimum requirements
2. Use of PDO instead of Creole
   1. New DSN format for build and runtime properties
   2. New transaction API
   3. Some method signature changes
   4. 'mysqli' adapter is obsolete & has been removed
3. New SPL autoload integration

Fore more information check the Upgrading Guide.

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.

Following the post about UTF-8 in the front-end of a Web application, these are some points to check in the back-end:

• Again, make sure your application source and data files are UTF-8
• Make sure the character set of the database is set to UTF-8
• Make sure the character set of the connection to the database is set to UTF-8. With Propel and MySQL, it's done like this:

  $con = Propel::getConnection();
  $con->executeQuery("SET NAMES utf8;");
  $con->executeQuery("SET CHARACTER SET utf8;");
  $con->executeQuery('SET character_set_client="utf8"');
  $con->executeQuery('SET character_set_connection="utf8"');
  $con->executeQuery('SET character_set_results="utf8"');

  Although MySQL reference on character sets says the last 3 statements are redundant, we experienced that it is not true. It is however more likely an issue with Propel/Creole, not MySQL.
• Make sure the PHP functionality you are using handles UTF-8 correctly (it is not supported natively). Check the list of UTF-8 “Dangerous” PHP Functionality.

Sometimes you may come up with a View that does nothing else than some additional filtering compared to a more general View.
For example, imagine a product catalog with nested categories. One way to create Views for it is to have a top-level ProductListView showing all the categories and all the products in them, and a View for each of the nested categories, e. g. ValveListView, CompressorListView etc. Then, this situation allows some nice code reuse via inheritance of the Views. The specific category ListViews inherit from the ProductListView and only do the additional filtering of the products, making sure only valves or compressors or whatever appear in that category.

One way to implement the filtering is making Propel's Criteria object (used for filtering the database results) a protected field of the ProductListView. The XSLT template can be overridden in the constructor as well, if necessary. It would probably also make sense to move the inherited View into a sub-folder of ProductListView, but then include paths have to be modified accordingly.

Here is how the final inherited ValveListView might look like:

class ValveListView extends ProductListView
{

	public function __construct(Resource $resource = null)
	{
		parent::__construct($resource);

		$this->template->load(ROOT_DIR."view/views/productList/valveList/ValveList.xsl");
	}
	
	public function display(Request $request, Response $response)
	{
		$this->criteria->add(ProductPeer::TYPE, ProductPeer::CLASSKEY_VALVEPRODUCT);

		parent::display($request, $response);
	}

}