<xml.lt>

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);
	}

}

GoPHP5 initiative encourages developers and hosting providers to drop PHP 4 from February 5th 2008 and support at least PHP 5.2 from then on.

PHP 5 has many new and improved features such as a better object-oriented model, improved XML processing, WebService, and database access APIs etc. However, many of the shared hosting sites support only PHP 4, and that makes difficult for many projects and users to exploit the new features of PHP 5.

This is of course a very welcomed initiative, but not really big thing for our team though. Right from the beginning, we did not plan any support for PHP 4 in our DIY Framework. We felt that the new features by far outweighed the need for legacy support. But for those of you who had similar thoughts, it's the best timing to move on to PHP 5!

UTF-8 is an amazing thing for Web developers, especially those developing multilingual or localized sites. It keeps you away from the mess of various encodings for different languages since you can find almost all of the world's character in a single Unicode charset. It is a default encoding of XML and other standards. In short, everybody is encouraged to switch to UTF-8.

However, starting developing with UTF-8 can give you some headaches, too. Usually you'll notice wrong characters, most often non-ASCII ones. The most common source of this is UTF-8 mixed with other encodings in the application or user input, i. e. assuming some characters to be UTF-8 when they are actually not, or erroneous conversion to/from other encodings.

A simple way to avoid problems is to make UTF-8 the encoding for the entire application. However, that might be simpler to state than implement. We can give you some hints for developing Web application's front-end:

• Make sure your application source and data files are UTF-8. Byte Order Mark (BOM) can cause problems in some editors or appear as unwanted program output, e. g. in PHP.
• Make sure HTTP response will be interpreted as UTF-8. This can be done using:
  • HTTP headers
    This is the way we use. Using a Response object from the DIY Framework, you can set it like this:

    $response->setCharacterEncoding("UTF-8");

    That later appears as a HTTP header in the response:

    Content-Type: some/type; charset=UTF-8

  • HTML's <meta http-equiv=""> elements, which mimic HTTP headers, e. g.:

    <meta http-equiv="Content-Type" content="some/type;charset=utf-8" />

  • XML declaration, e.g.:

    <?xml version="1.0" encoding="UTF-8" ?>

• Make sure user input is interpreted as UTF-8. Browsers usually submit data in the same encoding the page has. However, you can specify it for forms explicitly:

  <form accept-charset="UTF-8">

• Check your locale, environment, and/or web server settings for UTF-8 if they influence the encoding of your application's output. For example, there is default_charset in PHP and AddDefaultCharset in Apache.

Next time, some hints for the back-end will follow. More information on W3C I18n: Character encodings and SitePoint's Scripters UTF-8 Survival Guide.