townx - I Hear a Symfony: Rails vs. the Symfony PHP framework - Comments

This Drupal site is on

elliot — Wed, 10 Dec 2008 14:34:17 -0600

This Drupal site is on shared hosting. I wouldn't use any other blogging system. Wordpress would have been my suggestion, but sounds like you've already decided you don't like it much.

I am just a blogger and

Leonardo Medina — Wed, 10 Dec 2008 00:01:25 -0600

I am just a blogger and nothing else so I am not in that all technical programming language so just goign to ask a very simple thing. I am tired of wordpress upgrades so moved to Drupal. I started loving it but my host don't. They refrain me to use it because i was on a shared host. Now IO am looking for another blogging system which should work like Drupal. So is it somethign similar to that? I am talking about Symphony.

Hi Ben. I'm not aware of any

elliot — Thu, 01 Nov 2007 15:17:20 -0500

Hi Ben. I'm not aware of any CMSs written with Symfony. I'd go for Drupal under any circumstances :)

What CMS's run well on Symfony?

Ben Fajen — Wed, 17 Oct 2007 12:24:10 -0500

We're strongly considering moving to Symfony from our own CMS system which we built using PHP with Smarty templating. We need to find the best, most flexible, most powerful CMS available if we go in this direction. Can you recommend any particular CMS for use within Symfony?

Thanks for letting me know

elliot — Tue, 14 Aug 2007 05:30:45 -0500

Thanks for letting me know about that. I too have had issues with Propel, as it seems pretty clumsy and inflexible in places. I will mention Doctrine in the article and have a look myself.

About the Symfony framework

hartym — Mon, 13 Aug 2007 12:20:36 -0500

Hey, glad to see the symfony web sphere is getting bigger and bigger. As a symfony user/developper since two years now, i'm happy to see how it's used by more and more people. But maybe you could point out that Propel is not the only O.R.M available for symfony, an under-development ORM called PHP-Doctrine is increasing stability every day, and as the #doctrine channels topic clams, "RC 1 to be released at 31st of August". Doctrine is far mor contraining than Propel, as it does not generates static methods but insteads allows you to make complex arbitrary joins in your schema following the DQL (Doctrine Query Language). I worked for one year with propel, and headaches came so fast i had to find a solution. Even is doctrine is not yet 100% ready for production use, it will be soon, and i personnaly use it in production on some small sites already.

Keep spreading the word :-)

Cheers, glad it was useful

elliot — Mon, 13 Aug 2007 10:37:27 -0500

Cheers, glad it was useful and thanks for taking the time to comment.

Nice one! Glad you found it

elliot — Mon, 13 Aug 2007 10:35:26 -0500

Nice one! Glad you found it interesting.

Propel queries

Scott Meves — Sat, 11 Aug 2007 12:09:56 -0500

This was a great article! In case anyone was following along, I believe you could reduce your retrieval function even more and use the "doSelectOne" method available in your base peer classes:


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

Fantastic, thnx...!

Skaldrom Y. Sarg — Sat, 11 Aug 2007 03:28:37 -0500

Thank you very much for "getting your hands dirty" and sharing your expiriences with symfony. Such a review from someone who has actually coded something is much more valuable than all those comparisons that only show information gathered from different websites.

Thanks for commenting. I

elliot — Sun, 08 Jul 2007 02:18:29 -0500

Thanks for commenting. I tend to agree: symfony is a bit big and complex, and I had a hard time getting my head round some of it (the Apress book is OK but not particularly task-oriented: it explains where everything is and what it's for, but not how to use it). I've been working with Propel and Smarty this weekend, and have managed to put together a fairly lean and simple MVC framework in about a day, with some quite Rails-like features but without the complexity of symfony. I might have a go at building something with that, rather than symfony.

Thanks for the Great Post!

Ed — Fri, 06 Jul 2007 11:27:46 -0500

Great post. I was looking for a rake-like helper for PHP (Pake, as you mention) and decided to keep reading to hear what other tools Symphony offers. I initially considered using Symphony to build my latest web app but decided against it for performance reasons. I think it's most sensible (for both pragmatic and performant development) to use a "best-of-breed" composite framework, taking the best (hopefully decoupled) bits and pieces from existing solutions and using those where applicable, thus avoiding the standard framework bloat. Thanks again for the writeup!

Thanks Adrian. I think my

elliot — Tue, 05 Jun 2007 03:22:38 -0500

Thanks Adrian. I think my experience was similar to yours: nice, but more painful than Rails. Though I did wonder whether this was because I know Rails pretty well, and Symfony not at all, so maybe my existing experience was colouring my perceptions. I found the documentation OK as far as tutorials went, but the API documentation a bit lacking in explanation.

2 cents.

Adrian — Sun, 03 Jun 2007 22:15:52 -0500

Nice review. I've been using Rails for several months, but as a new project had PHP as a requirement I adopted symfony for that. While it is a decent framework indeed, I still found it to be rather painful compared to Rails (and Ruby, that is). Several features are lacking, but more importantly the documentation is rather poor and, at times, not helpful at all. The community support is nowhere as good either. It was a good experience nevertheless, but I am very much looking forward to going back to Rails...

Thanks Michael, that's a

elliot — Fri, 16 Mar 2007 16:48:48 -0500

Thanks Michael, that's a nice compliment. I'll definitely be looking at Symfony again for my next PHP project. Thanks for the routing tip too.

I Hear a Symfony: Rails vs. the Symfony PHP framework

elliot — Wed, 31 Jan 2007 07:58:12 -0600

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...