Enjoy!

Despite all this good stuff that you get for free, xhtml, or rather the xhtml media type (application/xhtml+xml) has its problems. And one of those problems is webkit.

Mobile devices are incredibly important in modern web development, so designing for the capabilities of those devices is just part of a standard workflow. The problem however, is that webkit on these devices prefer application/xml and application/xhtml over our friend, text/html. Take a look at the following Accept header sent by two desktop browsers (Firefox and Chrome):

Accept: text/html,application/xhtml+xml,application/xml;q=0.9, */*;q=0.8


Contrast this with what is sent from the iPhone (iOS 4.3.5):

Accept: application/xml,application/xhtml+xml,text/html;q=0.9, text/plain;q=0.8,image/png,*/*;q=0.5


And further, and Android phone (2.3.5):


Accept: text/xml, text/html, application/xhtml+xml, image/png, text/plain, */*;q=0.8


And suddenly we have a problem. If we use application/xhtml+xml then we have to account for iOS and Android devices preferring it over text/html.

There’s two things we can do to counter this. The first is to put a filter in front of your application to detect the user agents for browsers that are known to prefer the xml/xhtml representation that we want to reserve for our API clients. This is an application specific solution – you have to know that the browsers that you are filtering and then rewrite the Accept header so that text/html is served up by your application. You also have to accept that requests from those browsers will never be issuing requests against your web service as those requests will be rewritten to text/html.

The second solution is to use a vendor specific media type, and serve xhtml up on that. This means that you lose a small part of the self describing nature of using application/xhtml+xml – but means that you can be absolutely certain that no existing browser will prefer your API content over what it should be seeing. Vendor media types take the format of application/vnd.. – for example application/vnd.fdrop.xhtml+xml

Opinions on which of these two options are preferred (or if you have heard of other solutions or have any suggestions on other ways of dealing with this) would be most welcome.

Zend Yellow Pages

http://techportal.ibuildings.com/2010/09/20/building-a-continuous-integration-server-for-php-with-hudson/

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

class Price
{
	protected $value = 0;
 
	protected $currency = null;
 
	public function __construct($value, $currency = 'GBP')
	{
		$this->value = $value;
		$this->currency = $currency;
	}
 
	public function getValue()
	{
		return $this->value;
	}
 
	public function getCurrency()
	{
		return $this->currency;
	}
 
	public function __toString()
	{
		return "{$this->value}";
	}
}

That’s all you should need for the price. Think about the money in your pocket – it has two property’s. It has a value, and it has a currency. I cannot change either without spending it (or converting it at a bureau de change), but then I would get a set of new coins in return. It has no concept of whether or not it is inclusive or exclusive of tax. Thats up to something else…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

class TaxMan
{
	protected static $vat = array(
		'GBP' => 15.0
	);
 
	protected $currency = '';
 
	public function __construct($currency)
	{
		if(array_key_exists($currency, self::$vat)) {
			$this->currency = $currency;
		} else {
			throw new Exception('Cannot build a TaxMan for this currency');
		}
	}
 
	public function getVat(Price $price)
	{
		return new Price(($price->getValue() * (self::$vat[$this->currency]) / 100), $this->currency);
	}
}

So we can pass in a price object and get a new value representing how much vat should be added… Something like this.

1
2
3
4
5

$price = new Price(8.00);
$taxman = new TaxMan('GBP');
$vat = $taxman->getVat($price);
 
$total = new Price($price->getValue() + $vat->getValue(), $price->getCurrency());

This is not completely finished however (and I may come back to it to complete it), as it’s completely possible for multiple different tax levels within a currency (Currency can be used in multiple countries, or different products have varying levels of VAT associated with them). This will solve some of the problem – but there’s more work to be done.