How to create an optimized version of your website for the iPhone in symfony 1.1

symfony 1.1 introduces native support for different formats and mime-types. This means that the same model and controller can have different templates based on the requested format. The default format is still HTML but symfony supports several other formats out of the box as defined in the factories.yml file:

request:
  class: sfWebRequest
    param:
      formats:
        txt:  text/plain
        js:   [application/javascript, application/x-javascript, text/javascript]
        css:  text/css
        json: [application/json, application/x-json]
        xml:  [text/xml, application/xml, application/x-xml]
        rdf:  application/rdf+xml
        atom: application/atom+xml
 

Each format is associated with one or more mime-types. These mime-types are used to automatically determine the requested format by parsing the Accept HTTP header. This comes in very handy if you want to make your data available via a browser and expose them as a Web Service. To change the format of the response, a Web Service client can just change the Accept header as shown below:

$ curl -H "Accept: application/xml"  http://ws.example.com/api/article # to get a XML representation of the data
$ curl -H "Accept: application/json" http://ws.example.com/api/article # to get a JSON representation of the data

Supporting different formats is as easy as creating different templates. So, let's say the web service is managed by an api/article action. Here is the list of templates you have to create in apps/frontend/modules/api/templates to support HTML, XML, and JSON formats:

  • articleSuccess.php
  • articleSuccess.xml.php
  • articleSuccess.json.php

By default, symfony will change the response Content-Type according to the format, and for all non-HTML formats, the layout will be disabled. Even partials and layouts can be different based on the requested format. For example, if you include a list partial in a template, the loaded partial name will depend on the current format:

  • _list.php
  • _list.xml.php
  • _list.json.php

Let's take another example. You want to create some stylesheets or JavaScript files on the fly. As you can't always rely on the browser Accept HTTP header for those cases, you can force a format by using the special sf_format variable in your routing rules. Here is how to create a route for a dynamic stylesheet:

css1:
  url:   /css/dynamic1.css
  param: { module: css, action: dynamic, sf_format: css }
 

You can also use the sf_format variable in the URL pattern to allow several formats for one action:

api_article:
  url:   /api/article.:sf_format
  param: { module: api, action: article }
  requirements:
    sf_format: (?:html|xml|json)
 

Most of the time, you don't have to change a single line in your actions to support new formats; but if you really need to do something special for a format, you can call the $request->getRequestFormat() to get the current format and act accordingly.

Ok, now for the fun part! Let's say you want to create an optimized version of your website for the iPhone. The iphone format does not exist by default but it's pretty easy to configure one. First, we need a way to determine that a request comes from an iPhone. If the User-Agent header contains the words Mobile and Safari, we can safely guess that the browser is an iPhone. We can put this logic in the ProjectConfiguration class by registering a listener for the request.filter_parameters event:

// config/ProjectConfiguration.class.php
class ProjectConfiguration extends sfProjectConfiguration
{
  public function setup()
  {
    // ...
 
    $this->dispatcher->connect('request.filter_parameters', array($this, 'filterRequestParameters'));
  }
 
  public function filterRequestParameters(sfEvent $event, $parameters)
  {
    $request = $event->getSubject();
 
    if (preg_match('#Mobile/.+Safari#i', $request->getHttpHeader('User-Agent')))
    {
      $request->setRequestFormat('iphone');
    }
 
    return $parameters;
  }
}
 

Now, everytime a request comes in, the filterParameters() method is called and if the browser is an iPhone, the request format is changed to iphone.

That's all! Now, every request from an iPhone will use *Success.iphone.php templates instead of *Success.php templates.

If you use some special stylesheets of JavaScript files to support the iPhone (for example if you use the iui library), you can also configure the view by listening to the view.configure_format:

class ProjectConfiguration extends sfProjectConfiguration
{
  public function setup()
  {
    // ...
 
    $this->dispatcher->connect('view.configure_format', array($this, 'configureIPhoneFormat'));
  }
 
  public function configureIPhoneFormat(sfEvent $event)
  {
    if ('iphone' == $event['format'])
    {
      // add some CSS, stylesheet, or whatever you want
    }
  }
}
 

Today, Apple launched the new iPhone 2. To celebrate this event, I'm pleased to announce that the symfony API documentation is now available for the iPhone with a specific interface as you can see in the screenshot below.

Thanks to the new format support in symfony 1.1, developing websites that supports Web Services, API or the iPhone has never been easier. Supporting a new format is as easy as creating a new set of templates. Enjoy!

How to create an optimized version of your website for the iPhone in symfony 1.1 symfony.com/blog/how-to-create-an-optimized-version-of-your-website-for-the-iphone-in-symfony-1-1

Tweet this

Comments

You guys are doing such an amazing job making us NOT THINK about anything!.
thanks.
sf still the best

Symfony FTW!
Thank you for this beautiful framework!
Is not just a framework, is a way of life!
Thank you!
It took me a few minutes to get this up and running. There are a few minor corrections to your example.

The method name, 'filterRequestParameters' doesn't match the one in your connect call, 'filterParameters'.

I needed to replace '$dispatcher' with '$this->dispatcher' - maybe that was implied by '// ...'?

And you also need to create a layout called 'layout.iphone.php'.

:)

Other than that -- it's gorgeous!


// config/ProjectConfiguration.class.php
class ProjectConfiguration extends sfProjectConfiguration
{
public function setup()
{
// ...

$this->dispatcher->connect('request.filter_parameters', array($this, 'filterRequestParameters'));
}

public function filterRequestParameters(sfEvent $event, $parameters)
{
$request = $event->getSubject();

if (preg_match('#Mobile/.+Safari#i', $request->getHttpHeader('User-Agent')))
{
$request->setRequestFormat('iphone');
}

return $parameters;
}
}


@dave: thanks for the feedback. I've fixed the examples.
Ah, hells yeah. This is nice. I am currently spitting out json and html for one of my projects, but this method is much cleaner.

Looking forward to start using 1.1.

Do validators work with this?
This looks impressing!

Is there some docs on customizing sfProjectConfiguration and an explained list of those events like view.configure_format you can modify?
@Jordi: All the events are described in the symfony book:

http://www.symfony-project.org/book/1_1/17-Extending-Symfony#Built-In%20Events
Holy shot. That's the release I've waited for a long time :) Great job and thank you for your efforts, and making symfony OSS!

I'm looking forward to the 1.1 stable release.
Great! Me as well looking forward to start projects based on 1.1.
I presume the iPhone stuff is identically working for the iPod-Touch as well, as the latter is based on the same software system as the iPhone (e.g. Mobile Safari)?
Cheers RAPHAEL
What a very great news :p
Nice, but why iPhone? There are tons of other mobile phones too... Rather than optimizing for iPhone, it'd be much better to optimize for all small screen devices.
iPhone will rule da world.
the routing rule :
url: /api/article:.sf_format
should be:
url: /api/article.:sf_format ?
@reeze: you're right. It was a typo. Thanks.
From looking at this post I assume templates can be created for things like SOAP and REST calls as well? In other words, instead of a template that works on an iPhone, a template could be created to present the sfActions as web services? I may be off the mark a bit (please forgive me, I'm a PM, not a coder...)
UA-sniffing and device specific versions of a website. What year is this? 1997? Haven't you guys heard of Web Standards?

One may make a site for small screens. But to make a site for a specific device is really bad practice.

And the iPhone support @media CSS-rules. That should be the first choice if you want to arrange stuff for the small screen. Incidentally that also is supported by Opera and will be by Firefox 3.1 and therefore also Fennec.

Using the wrong tool for a job is not a good route to go down, even if that tool is really well designed.
Lars, what if you want a different html output for the iphone ?
@Hans

a. If your pages are so bloated that you must use different HTML output I would presume you need serious IA refactoring.

b. The very point of Apples marketing is that the iPhone should not get mobile specific versions of a website. And they specifically chose not to honor @media handheld but uses @media screen rules. By using such a device a customer has chosen to view the full version. Ergo: use "@media screen and max-width()" if you need to adapt.

Incidentally, that will also work for all users of Opera Mini (which is a larger audience than the iPhone's!) and Opera Mobile, as well as the upcoming Fennec.

c. UA sniffing has been proven beyond all reasonable doubt to be a faulty solution. It will only lead to UA-spoofing. We really have been there before! To repeat a previous mistake but expect a different outcome is just plain stupid.

So:

If you really must send alternate content to mobile devices (not just the iPhone), the least sucky solution is to use a different URL and let the user choose.

Of course that can lead to surprises when the mobile version ranks higher on Google. Just like many sites using the faulty approach of having "print versions" experience today.

But as I said to begin with. If your IA is bad, that is where you should attack the problem. It is better than creating new ones.

Comments are closed.

To ensure that comments stay relevant, they are closed for old posts.