Wednesday, 2 January 2013

Getting to know Symfony

During Christmas holidays I've decided to dive into Symfony. If you don't know anything about it - it's very nice modular web development framework. Not so long ago Drupal got some low level components from Symfony: It was a very interesting merge of the two systems. I was a bit surprised, like when your little sister puts her Barbie into your Ferrari toy car. But as expected it's a well thought though decision: easier maintenance, benefits of small domain components (such as http kernel) and a versatile management system (Drupal, ofc.), merging communities, etc.

Also, for me it's a final eye opener. The Drupal learning curve is a nice path to walk on - until you hit a new release. New API, new core features, start to learn again. Using Symfony components (and in Drupal 8 even other ones, like Doctrine or Propel) let you to get familiar with a well known codebase and reuse it though many upgrade cycles. That's a nice thing to have for sure.

By the way I'm not sure if you realized - and that's a bit bugging me - having these high level abstraction layers (Drupal, Symfony or any other frameworks) will generate a growing challenge when learning something new. Back in the early days if you knew Fortran or Assembly you could create a large variety of applications - required in that time. Healthcare, analytics, mathematics, graphics, etc. The fact that the tool was very limited - couple of low level languages - made the learning phase "easy". Now DSLs and libraries and frameworks can serve extremely more type of problems in much bigger details. However there moving between those targets are quite hard. Imagine learning JSP and then ASP and Drupal and Haskell and ... geez it sounds so sexy and just impossible at the same time. If you see evolution works the same way - but let's talk about that another time.

So how was my first hands on experience with Symfony?

First I wanted to see it work. Pretty easy - download the package (with all vendors) - put to your webroot and launch: /web/app_dev.php
Then - seeing it works - I was looking for some 'helloworld' tutorial. There is a great howtostart guide that explains the architecture in a nutshell.
There was the first suspicious part - configuration. (Let's state here - I'm new here, so even if I say it's strange it only means I'm not yet familiar.) There are many configurations at several locations. Routes, credentials, security, entity models ... and the whole shebang. I can see the value of distribution in well defined targets, where a config file serves a well defined purpose. However having it distributed makes it a hassle to lookup and maintain. In Drupal I like that we have a settings.php for all configurations - can be separated to a deployment-stage and personal settings file too if needed (and it's usually needed).

The concept of routes, controllers and the components are really great. Especially that all is optional. Drupal is trying to go there - still.

I don't like the way components are handled by the so called 'managers' - if I'm correct. It's all coming from the dependency injection framework - where we lose all the type information. I guess it's just me, but it's annoying that I cannot get proper code completion. I was doing a little research but none of them worked with Symfony's structure. Well - still I blame DI for that.

Then the second strange thing was the project structure. I know it's new, but creating a simple bundle requires - in general - a pretty complex folder and namespace structure. However it was pretty easy to create my first bundle. For that I looked for and found a pretty nice entry level book. It explains all stages and steps in a not too bad format. I say not too bad only because some parts was a bit of a pain to lookup. Anyways. What I wanted is a simple blog: list + creation.
Here you are the sandbox:

So in a nutshell:

  1. loading /web/app_dev.php/list will first invoke the Symfony framework bootlader
  2. sometime checks the router:
    1. it finds /list and realize it's mapped to [ItaratoBlogBundle:Default:index]
  3. so it opens indexAction() in
  4. the index function builds a form using the form type class
  5. the function then builds up a result HTML code using the view
  6. in that view it happens to be a call ({% render "ItaratoBlogBundle:Default:blogPostList" %}) for the blog post list: blogPostListAction()
    1. it collects all the items using the Doctrine ORM and another view
  7. and tada.wav
It's really not clear what is the magic behinds it but I'm sure it becomes more and more obvious soon.

So it's actually functional and works. Whew. However I still feel insecure about this due to the massive background support of the Symfony framework. I would like to see a best-practice debug process currently it's easy to lose my head in the debug function stack trace. Especially when if it's $something->get(this)->get(that)->getManager(oyeahthatrandomthat)->do().

In a few words about the available materials - I've found the online docs a bit short. They have docs about all the important pieces - but it seems they are quite special. You need to read code.

There are well developed bundles available for free. I'm about try some. Many looks really useful. However I'm still looking desperately for Drupal module clones.

Wrapping it up - I'm very excited to learn more Symfony. It's awesome to develop in a modular OO framework. And yeah, I hope I can use in a real project sometime.


To the readers - already Symfony developers: what blogs I should follow? Where can I read about the practical way of Symfony development? What are the good projects to tear up and see their anatomy?



  1. I think Eclipse has code completition support for Symfony2 DI and PHPStorm has an active feature request too.

    1. Wow, thanks a lot Adam. I wasn't really sure that this is the problem - but your help seems to be a solution. Great thanks :) I'll let you know how it went.

  2. This is pretty useful for generating code skeleton for bundles (among others):

    1. Hi Balint, I didn't know that :) Seems cool. Actually I was using the console tool for couple of things - I've forgot to mention in the article.
      Like creating a bundle:

      $ php app/console generate:bundle --namespace=Acme/HelloBundle --format=yml

      Or creating entities:

      $ php app/console doctrine:generate:entity --entity="AcmeStoreBundle:Product" --fields="name:string(255) price:float description:text"

      It's also a useful tool.
      Thanks again :)

  3. The best way to learn Symfony is by joining the IRC channel #symfony on freenode and talk to the people there (Symfony has a awesome community). The Symfony cookbook has also a lot of useful information. Useful is this tutorial too even it's Symfony 2.0 (so no composer support and the form handling has changed a lot in Symfony >= 2.1) but the basic architecture of a Symfony app hasn't changed.

    1. Hi Florian, thanks for the help :) Just entered to the IRC room, yeah - there are quite some people here. The 2 books I've already found, also got this book: (However it's Symfony 1.)
      Btw composer was a bit tough to setup. And still not sure how to use it properly. Probably I need to RTFM a bit better :)

  4. my sources:

    1. be careful. symfony and symfony2 are very different

    2. Hi Balazs, thank you very much :) Subscribed to all.
      Yeah I know - actually I think it really doesn't worth to read or learn by any Symfony version 1 materials - am I right? Of course if I want to learn Symfony 2. However I haven't found any larger books about the second version.

    3. Did you check this book?

    4. Yup, that I already have? Almost read it though :)

  5. This comment has been removed by the author.


Note: only a member of this blog may post a comment.