townx

No Ruby Tuesday this week, as I've not been Ruby programming. Instead, I've been having a look at the Symfony PHP framework, to see whether it shapes up to Rails. As I've stated previously, Rails is a pain to run on dirt-cheap hosting (though options like Planet Argon are out there, cheap enough, but I haven't tried them yet); plus Ruby is another language to learn for the people I work with at OpenAdvantage, and most of them have got enough to do running small businesses. I wondered whether Symfony is good enough to recommend as an alternative to Rails for programmers who already know PHP.

In short: it is.

It's not perfect, not as concise as Rails, and lacks many of the features. But using it is a damned sight easier than writing a PHP application from scratch. I'm not going to do a thorough feature listing (see the Symfony site for that). Instead, here are some of the notable things about it that improve the life of PHP programmers:

• It bundles in the Propel Object Relational Mapping layer for PHP. I'd heard of this but not used it before. It feels similar to "Torque" for Java, and isn't as neat as ActiveRecord, mostly because PHP lacks some of the advanced meta-programming available in Ruby. This means you end up with getters and setters when you create classes which "peer" for your tables (not neat methods as in ActiveRecord). You also get four classes per table: a Base class, a BasePeer class, a class representing the table (inherits from Base) which you can append methods to, and a peer for the table (inherits from BasePeer) which you can also append methods to. Much more verbose than ActiveRecord. (Note: hartym (see comments) mentions that Doctrine is also available as an alternative ORM layer for use with symfony. Might be worth a peep.)
• It includes a build tool called Pake, which works in a similar way to Rake but for PHP. This means there are scaffold and migration style tasks you can run.
• There are separate frontend and backend scaffolding tools. The backend stuff reminds me of Django or Streamlined.
• It has a built-in (simple) authentication system. However, the fact that someone has thought about authentication probably means it's easier to work into an application than it is in Rails.
• Internationalisation and localisation are supported out of the box.
• It has more of a sense of structuring applications than Rails does, perhaps closer to Django. This could mean I could more easily move chunks of functionality around between Symfony applications without having the awkward feeling Rails plugins give me.
• There are far more configuration files (YAML). It feels more like Struts to me than Rails: you can tweak settings at various levels of granularity (whole of Symfony, per application, or per module). This is good in one sense (for example, validation is carried out in config. files, rather than in model classes, which makes it easier to share validation code around or tailor it for different actions). On the other hand, you do get a splurge of files to manage.
• It's PHP, so it will run on bog-standard web hosting, backed by any Propel-capable database (including MySQL).
• By default, it uses SQLite for the database in the development environment. Configuration works in a similar way to ActiveRecord's and is straightforward.
• AJAX support is built-in (using Prototype and Scriptaculous), and it has the same concept of helpers as Rails. This means you can build interfaces in a similar way to Rails interfaces, and many of the methods have similar names.
• It is based around a model-view-controller architecture, with a front-controller, very similar to Rails.

Next, a few specifics and code samples to give an idea of how it works.

My specific experiences

I chose a wiki as the project to experiment with, and have spent about a day and a half coding in Symfony. The result (fancifully called Flow My Thoughts, The Policeman Said) is an extremely simple wiki which supports camel-case links, [[]] links and Textile markup.

For the wiki parsing part of it, I borrowed some code from the Drupal freelinking module and from TextilePHP. Along the way I fixed TextilePHP so that it works properly with strict error reporting on (there were lots of references to unset variables and possibly non-existent array indexes which meant I got around 100 error messages the first time I ran it). This means I can write wiki links as well as mix in Textile markup (I am a big fan of Textile). Don't you just love open source?

For the main part of the project I started with the Symfony sandbox download, as this includes all the libraries for Symfony in a tarball. You can also install the dependencies with PEAR, and would want to if using Symfony for several projects. I also went with SQLite for experimenting with.

The model

First off you edit a schema.yml file with details of your data model. This works pretty well, and is a bit like writing a migration. You can either use the sensible Symfony defaults or work with the Propel syntax directly (e.g. if you want specific options or indexes set for fields). My model looks like this:

propel:
  page:
    _attributes: { phpName: Page }
    id:
    title:       { type: varchar, size: 255, index: unique }
    content:     longvarchar
    created_at:
    updated_at:

Nothing too unusual there. Also notice the "magic" Rails-style fields, created_at and updated_at.

To build the model classes from your schema, you run:

php symfony propel-build-all

The symfony file is a Pake build script. The propel-build-all task generates some XML from your YAML files, which gets converted into PHP classes representing your tables. In my case, I got four files: BasePage, BasePagePeer, Page, PagePeer. Then it generates some SQL and builds your database. All very migration-like. However, there's no sense of "up" and "down" in Symfony, and it's probably hard to version the database schema incrementally, like you can in migrations.

As I mentioned above, the PHP classes are chock-full of getter and setter methods. Far more wordy than ActiveRecord's default two-line class definitions, and a consequence of the lack of runtime class extension in PHP. However, only the Base classes (in my case, BasePage and BasePagePeer) are regenerated when you recreate the model using Pake. This means you can add your extensions into the classes which inherit from the Base classes (i.e. Page and PagePeer).

Scaffolding

Symfony supports generation of a CRUD interface (i.e. scaffolding) from the model too:

php symfony propel-generate-crud frontend page Page

This actually creates an application called "frontend" inside your app. directory. This is interesting, as it illustrates how Symfony applications can be structured into parent-child relationships, unlike Rails where it's pretty flat.

You can get at your application in development mode by browsing to (e.g.) http://localhost/frontend_dev.php/page. This will use the default views for the CRUD interface.

The scaffolding sits inside the frontend application, and can be used to selectively override the defaults for the application. I added some directories to my page module:

apps
  frontend
    modules
      page
        actions
        lib
          helper
        templates
        validate

Note here that I can either add helpers for the module, or I can place them under frontend > lib > helper to add them to the whole application. This mirrors the distinction between application level and controller specific helpers in Rails, but is reflected by the directory structure, rather than by file naming. This seems unnecessarily complex, particularly if you're used to Rails. The other directories are fairly obvious, hopefully.

Routing

Routing is one area which had me foxed. I wanted to be able to use a URL like this:

http://localhost/wiki/page/NameOfMyPage

to be able to navigate to the page with the title NameOfMyPage. However, I couldn't for the life of me get this to work. In the end I had to settle for:

http://localhost/wiki/page/show/title/NameOfMyPage

Note that the link_to helpers are a bit unwieldy compared to Rails, particularly as you don't have the luxury of symbols and automatic hashes from arguments like you do in Ruby:

echo link_to($page_title, 'page/show?title='.$page->getTitle());

Even though this is only slightly more opaque and verbose than Rails, I think it would wear on me after a while.

Actions

The scaffold specifies the actions you'd expect by default: for the page model, they ended up in apps/frontend/modules/page/actions/actions.class.php. Adding my own was simple enough. For example, I wanted to show a page by title. Showing a page by ID was supported by the scaffold already:

public function executeShow() {
  $this->page = PagePeer::retrieveByPk($this->getRequestParameter('id'));
  $this->forward404Unless($this->page);
}

Mmmm, not quite as succinct as Rails, I was thinking. You can see the Torque-style (Propel) syntax for retrieving records in the first line of this method definition. Note that the template to render is implicit, and maps to apps/frontend/modules/page/templates/showSuccess.php.

First, I added a new method to the PagePeer, to retrieve a record by title. This is located in lib/models/PagePeer.php, outside the application. The idea is you are likely to have multiple applications supporting a single model. On the other hand, it's probably possible to create models specific to individual applications (maybe even modules):

public static function retrieveByTitle($title) {
  $c = new Criteria();
  $c->add(self::TITLE, $title);
  return self::doSelectOne($c);
}

The Criteria class used here is part of Propel, and it works pretty well (again, very Torque-like). Though again, more verbose than ActiveRecord. (Thanks to Scott Meves' comment which cleaned up the above function.)

Then I added an action to frontend/modules/page/actions/actions.class.php:

public function executeShowByTitle() {
  $this->page = PagePeer::retrieveByTitle($this->getRequestParameter('title'));
  $this->forward404Unless($this->page);
  $this->setTemplate('show');
}

Notice that this reuses the 'show' template (setTemplate() specifies the one to use if different from the inferred template).

Helpers

I created my own helper to show error messages in apps/frontend/lib/helper/ErrorMessagesHelper.php:

<?php
function error_on($field) {
  $error = sfContext::getInstance()->getRequest()->getError($field);
  $out = '';
  if ($error) {
    $out = content_tag('div', $error, array('class' => 'error'));
  }
  return $out;
}
?>

Notice how I had to go round the houses to get at the error messages on the object. For some reason, error messages aren't stored on the object, but in the request. This makes them pretty hard to get at, and you have to use the Symfony context if you are not explicitly within a view. Also notice that there is a content_tag helper.

I can load this my helper into a template with:

<?php use_helper('ErrorMessages') ?>

Templates

Nothing special here. Just HTML with PHP, plus some PHP helpers to make life a bit easier. For example, here's my edit form for pages:

<?php use_helper('Object') ?>
<?php use_helper('ErrorMessages') ?>

<?php echo form_tag('page/update') ?>

<?php echo input_hidden_tag('id', $page->getId()) ?>

<p><strong>Title</strong> 
<?php echo object_input_tag($page, 'getTitle', array('size' => 80)) ?>
<?php echo error_on('title') ?>
</p>
<p><strong>Content:</strong><br/>
<?php echo object_textarea_tag($page, 'getContent', array('size' => '80x10')) ?>
<?php echo error_on('content') ?>
</p>

<hr />
<?php echo submit_tag('save') ?>
<?php if ($page->getId()): ?>
  &nbsp;<?php echo link_to('delete', 'page/delete?id='.$page->getId(), 'post=true&confirm=Are you sure?') ?>
  &nbsp;<?php echo link_to('cancel', 'page/show?id='.$page->getId()) ?>
<?php else: ?>
  &nbsp;<?php echo link_to('cancel', 'page/index') ?>
<?php endif; ?>
</form>

I could have used the short PHP <?= ?> syntax to make this less verbose, but went with the most portable syntax. Note that there are equivalents for Rails' form_remote_tag etc..

Validation

Validation is set up in YAML files (reminds me of Struts). For example, I wanted to make sure that both title and content are set for a wiki page. To validate an action, you have to add a YAML file named after the action: in may case, I wanted to validate the update action, so I added apps/frontend/modules/page/validate/update.yml:

methods:
  post: [title, content]
  
fillin:
  enabled: on
  
names:
  title:
    required: yes
    required_msg: 'Please enter a title for the page'
  content:
    required: yes
    required_msg: 'Please enter some content for the page'

Again, not as nice as Rails, but more declarative, perhaps. The fillin option has to be enabled for auto-form-population to be turned on.

Other comments

I haven't mentioned the testing framework which is built into Symfony, as I didn't use. Note also that it supports separate development and production environments, like Rails, but they run concurrently: you access the development environment through a modified URL, rather than by running the application in a different mode. That's quite nice.

Another feature I liked is the console you get in development. This shows you log messages pertinent to the page, the SQL queries run, and general stuff about the environment, presented as an AJAX-ified menu across the top of the app.. I'd love to see something like this in Rails.

I started putting Ajax into the application, but in-place editors don't work very well with wiki pages (you need to be able to click on links in the page when a page is displayed, but the in-place editor turns the whole page into a clickable field which displays an edit form, as in Rails). So I abandoned that. I also experimented with using the TITLE field as the primary key instead of ID (use of ID fields is encouraged in Symfony, as in Rails), but this was hard work, so I went back to IDs. I also didn't get round to authentication.

That's as far as I went with the application, and I'm unlikely to go further. I've attached it to this post for anyone who's interested (licence is GPL).

Summary

I put these few samples of Symfony code up to give a flavour of the differences and an impression of how it feels for a Rails programmer. It is not a thorough or complete evaluation. Try it for yourself. I have to say that the tutorial on the Symfony website is pretty good; and you can also get a full book on Symfony from the site (or a print version). (Come on DHH and Dave Thomas, when are we likely to see Agile Web Development for Rails given away? I've already bought it twice.)

Symfony has a lot going for it. It's pretty easy to get up and running. But by contrast with Rails, it is very verbose because of how PHP works. On the plus side, it is similar enough to Rails to make it fairly easy to transition to; and you can run it on normal web space at high speed without having to fork out for special hosting. That last point is very important to my mind. Coupled with the fact that there are lots of PHP programmers out there already, or Java programmers looking for a lightweight framework but scared of Ruby, and I can see it growing at a reasonable pace. I would certainly consider it if I needed to write a scalable web application for myself; I've even considered rewriting Flickrlilli using it, to see if it makes a difference and to get a better comparison. You never know...

Attachment	Size
fmt_wiki.tar.gz	1.58 MB