<xml.lt>

We have launched a brand new website. Now you can find more information on what we do and what we offer to companies and developers. We also plan to blog regularly :)

From the technical point of view, the website is fully searchable, has a valid XHTML markup and table-less fluid CSS layout as well as a RSS 1.0 feed.

When specified

<xsl:output method="xml" encoding="UTF-8" indent="yes"
doctype-system="http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"
doctype-public="-//W3C//DTD XHTML 1.0 Strict//EN"/>

in the stylesheet, libxsl processor incorrectly adds

<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />

This meta tag should only be added with method="html", not method="xml".

In many situations, strings have to be encoded using the % notation before put in the URL, to avoid confusion with reserved characters such as : or /.

XSLT 1.0 has no standard function for URL encoding. In XSLT 2.0, encode-for-uri() function can be used. However, there are solutions for URL encoding in XSLT 1.0.

In case of the ISO-8859-1 charset, one can use encoding/decoding stylesheets from skew.org. It gets much more complicated with UTF-8 and a pure XSLT solution is not realistic — extension functions have to be used instead.

Using PHP's XSL extension, PHP's functions can be called directly from the stylesheet. registerPhpFunctions() method has to be called on the XSLT processor instance and PHP's namespace (http://php.net/xsl) has to be included in the stylesheet before doing that. Then PHP's urlencode() can be called from the stylesheet in such a way: php:function('urlencode', string('value')).

For some transformations, the XSLT stylesheet has to have access to more XML documents than the main one. They can be accessed using the document() function which has to be given a document URI. It is trivial in case the document is a static file in the file system. However, most of the time such documents are formed at run-time. Our templating system is very much based on that. The solution is to give such documents a “fake” URI scheme (such as arg://) and create a way for the XSLT processor to read from it.

In Java, you'll need to implement your own custom URIResolver.

In PHP 4, which had an XSLT extension based on Sablotron processor, one could pass an array of document arguments to the xslt_process() function.

In PHP 5, it is possible to achieve this functionality using stream wrappers that intercept calls from stylesheets. In our framework we have implemented a simplified version of Java's URIResolver interface which uses code by Alexandre Alapetite as its base. For example, in a class extending XSLTView you can pass a serialized object like this:

$this->resolver->setArgument("document-name", XMLSerializer::serialize($object));

Finally, the XSLT code for side document access would be document('arg://document-name').

We are pleased to announce the release of our DIY Framework! It is an open-source web application framework based on MVC architecture, object-oriented PHP 5, MySQL, and XSLT.

The Model is database-backed and generated by Propel ORM tool, the Controller is inspired by REST and RDF, and the View is based on XSLT stylesheets as templates.

The framework allows clean and precise sever-side development with a fully object-oriented code, absolutely no mixing of PHP, (X)HTML and/or SQL code, resources that have nice meaningful URIs with no extra effort, and many other features. On the other hand, it is tiny, flexible, and not overloaded with buzzword things.

Get to know more about the framework and download it under Resources: DIY Framework!

You often want your views (especially those which list items) to do sorting, filtering, paging and that kind of things. Using Propel, you can achieve that by calling a few simple methods, without a single line of SQL!

Here is how our View class for listing blog posts looks like:

class PostListView extends XSLTView
{
	function display(Request $request, Response $response)
	{
		$pageForm = new PageForm($request);
		
		$offset = 0;
		if ($pageForm->getOffset() != null) $offset = $pageForm->getOffset();
		$limit = 10;
		if ($pageForm->getLimit() != null) $limit = $pageForm->getLimit();
		$desc = true;
		if ($pageForm->getDesc() == "false") $desc = false;
		$orderBy = 1;

		$c = new Criteria();
		$c->add(PagePeer::TYPE, PagePeer::CLASSKEY_POSTPAGE);

		$postCount = PagePeer::doCount($c);

		$c->setLimit($limit);
		$c->setOffset($offset);
		if ($desc)
		{
			$c->addDescendingOrderByColumn(PagePeer::DATETIME);
			$c->addDescendingOrderByColumn(PagePeer::TITLE);
		}
		else
		{
			$c->addAscendingOrderByColumn(PagePeer::DATETIME);
			$c->addAscendingOrderByColumn(PagePeer::TITLE);
		}

		$posts = PagePeer::doSelectJoinAll($c);

		$this->proc->setParameter("", "total-item-count", $postCount);
		$this->proc->setParameter("", "offset", $offset);
		$this->proc->setParameter("", "limit", $limit);
		$this->proc->setParameter("", "desc", $desc);

		$this->resolver->setArgument("posts", XMLSerializer::serialize($posts));

		$this->template->load(ROOT_DIR."view/views/postList/PostList.xsl");

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

}

The parameters are used for paging. offset specifies the number of posts to skip (i. e. the post number where the result should start at), limit specifies the number of posts in the result (on one page), and desc specifies whether it should be sorted in the descending order or not.

We just retrieve request parameters using a Form, pass them to Propel to do the sorting/filtering stuff (using Criteria and PagePeer classes), and then pass them to XSLT — that's it, the job is done.

Content negotiation is a mechanism defined in the HTTP specification that makes it possible to serve different versions of a document (or more generally, a resource) at the same URL, so that user agents can choose which version fit their capabilities the best [Wikipedia].

Negotiation is based on HTTP Accept headers that the clients send. It can be used for different things, such as determining client's language or locale, but we mainly use it to deliver our content with the right MIME content type. That is important when delivering XHTML since the correct content type for it is application/xhtml+xml while plain old HTML should be served with text/html.

These are the only 2 lines that do the negotiation in our XSLTView class. They serve the XHTML content type to clients that support it (Internet Explorer does not) or revert to HTML otherwise:

if (strstr($request->getHeader("HTTP_ACCEPT"), ContentType::XHTML_XML)) $response->setContentType(ContentType::XHTML_XML);
else $response->setContentType(ContentType::TEXT_HTML);

You might end up in a situation where several different Views contain identical or similar templates in their XSLT stylesheets.
For example, we have a PostListView for a general list of blog posts, YearlyPostListView for a list of posts from a specific year, and MonthlyPostListView for a list of posts from a specific month. While these are 3 separate views with 3 separate stylesheets, they all have to produce the same XHTML snippet for blog archive links (placed on the right) and keep the same look-and-feel. And, of course, you don't want to keep 3 versions of code that is supposed to be identical and make changes several times in different files.

There is a fairly trivial solution to it — extract that common template and place it in a separate stylesheet that the Views could include.
We do it by creating a stylesheet called common.xsl and placing it in the views/ folder (not one of the specific View folders) next to master.xsl. The XSLT code for including it from the specific Views is simply <xsl:include href="../common.xsl"/>.

Nowadays the web is accessed not only via computers, but through a range of various devices: handhelds, mobile phones, TVs and even game consoles. The websites are also being printed, projected on the screen, and read by voice synthesizers. Each of these media has its own specifics of presentation. You might want to have several different ways to render your website to give the user the most accessible experience.

Fortunately, you do not need to have different versions of your website like in the old days in order to achieve this. Here is where CSS comes to help. Using it, you can specify different style rules for different media types. This can be done in several ways:

• By placing links to CSS stylesheets with different media types in your (X)HTML code:

  <link rel="stylesheet" type="text/css" media="print" href="print.css"/>
  <link rel="stylesheet" type="text/css" media="screen" href="screen.css"/>

• By using the @media CSS rule that defines a media type for a set of rules in the block it encloses. This approach allows rules for various media in the same style sheet.

We used the second approach to make our website printer-friendly and hide the elements that are not wanted in the printed version. The CSS code now looks like this:

/* Common rules */
html, body { font-family: "Verdana"; font-size: 10pt; }

/* Screen rules */
@media screen
{
	body { margin: 0; }
	/* ...more screen rules */
}

/* Print rules */
@media print
{
	div#header, div#footer, div#right, p.comment-controls, p#paging { display: none; }
}

We had a goal to use only object-oriented PHP code in our DIY framework. However, this is hard to achieve when even the basic and probably the most used constructs in PHP such as $_GET or $_SESSION are not object-oriented in itself.

For that reason, we implemented lightweight object-oriented wrappers for these constructs with basic functionality. The interface design was taken from Java Servlet API. The classes are as follows:

MultipartRequest

Provides OO access to $_FILES. API taken from Java's MultipartRequest.

Request

Provides OO access to $_GET and $_POST. API taken from Java's HttpServletRequest.

Response

Provides OO access to headers and the header() function. API taken from Java's HttpServletResponse.

Session

Provides OO access to $_SESSION. API taken from Java's HttpSession.

When you download the framework package, you will find the implementation in the controller/ folder and API documentation in docs/ folder.