Although I gave Ruby on Rails a small try a little while back, I ended up not choosing it as my framework for the moment mostly because I felt that there was a double learning curve in familiarizing myself not only with the Rails framework but Ruby as well. I still would like to give Rails a shot another day but for the moment I want to focus on getting a project completed. Of course, I would like to try something new as well which is why I decided to investigate Symfony 2.
I’ve worked with CodeIgniter and more extensively Kohana and the Zend Framework in the past but wanted something similar to Rails. After looking at the Zend Framework version 2, I felt that Zend had become excessively and unnecessarily bloated to the point where it was either unusable or cumbersome to learn. In the case of Kohana, it’s a leaner framework but not in as much use compared to Zend nor CodeIgniter (even though Kohana was forked from CodeIgniter). When I used Kohana for myself, two major issues I found that hampered my development slightly was the lack of a really solid model framework and having some issues attempting to integrate it with Zend’s model system because of conflicting naming problems (one used camel case and the other didn’t which could confuse the autoloader at times).
In turn, I decided to find something a little more complete with a good community, solid documentation and a decent architecture. A friend/ex-coworker turned my attention to Symfony 2. Originally, I looked at Symfony a while back, hearing various issues with performance and having to deal with various conventions that were popular at the time and the rigid model system that was Propel. However, he convinced me that essentially Symfony 2 != Symfony. With an open mind, I decided to give it another look.
The first thing that I had to deal with was upgrading my PHP on my Mac as Symfony 2 uses some newer features such as namespaces. Once I had the basics of configuring my system to work with Symfony 2 (which wasn’t that difficult to be honest), I was able to deploy a demo on my local system. One really cool thing off the bat that Symfony 2 offers is a built in web server. Eventually, you’ll probably use something like Apache to handle Symfony 2 but it’s nice having a sandbox for development.
You get Symfony 2 by using Composer. I’m not 100% familiar with Composer but it seems like it’s getting a lot of attention as one of hot PHP management tools. What I like about this is that you can manage your versions through Composer, which seems to intelligently set everything up for you. Once I get more into detail with Symfony 2 and Composer I hope to use this for my own stuff.
Next, Symfony 2 has a nifty tool called console which operates at the command line to do a lot of the boilerplate task such as generating your application, creating bundles and handling your entities (models). You can still hand code everything but it’s great having tools to automate the boilerplate aspects.
The thing that intrigues me the most about Symfony 2 is the architecture. In Symfony 2, everything becomes a bundle. Bundles are pretty much like libraries or mini applications that are well isolated but can be easily overridden. This aspect will help in large scale architecture that I can see because of how you can focus on componentization of your code such as creating a blog, forum, comments system, etc. Then you can enable/disable and pick and choose which bundles you want to integrate into your system.
Symfony 2 for the most part follows the generic ideas of an MVC system but I think they do a decent job of splitting up the tasks. Each segment is truly independent of the other and you can mix and match systems/services as you wish. For instance, for the the models, you can employ Doctrine or Propel. Neither are really tied to Symfony 2 and I’m guessing you could import other Frameworks’ models as well with the proper coercing of code. The views are Twig but you can use plan PHP files too. What matters is the configuration which allows you to specify the type of system you want to use. By doing things in this manner, you get a fairly flexible system that will allow you in the future to switch things around in case new or improved systems come about.
Up until this point, I’ve been using their online book to learn how Symfony 2 operates. Currently, I’m learning the Doctrine system and will comment on that along with the other pieces of the Symfony 2 architectural puzzle that I’ve managed to work with thus far. First, I want to talk about Twig a little bit. Twig is Symfony 2’s default view engine and it reminds me a bit of Smarty, except perhaps a little better done. The one stand out concept that Twig offers that has impressed me is the template inheritance system. Most templating systems focus on the separation between presentation logic and code for front end developers (which these days might become a massive joke since front end developers end up being highly versatile anyway). However, Twig takes one more step by creating a near OOP model that allows one to treat each template almost like an object. Blocks are kinda like methods that you can override when another template extends a parent. So you’re not merely doing includes that trickle one way in this system; instead, you’re just re-defining how structures appear between templates.
The next aspect I want to discuss is controllers. Symfony 2 controllers are pretty standard in how they process requests that get mapped to actions methods inside of the controller object. However, there are a few interesting concepts that Symfony 2 does which I really like. First, you can use annotations to declaratively handle URL patterns, etc. for the action methods. You can do things like define formats and route patterns then have those match the appropriate output. Using some naming conventions that map your formats to your templates, you can easily create flexible output services that allow you to render all types of stuff like JSON, XML, RSS, etc. just by defining the format. To me that’s pretty slick.
Another really interesting feature that is using the response output from other controllers inside of your controller as well as inside of templates. What’s neat about this feature is that you can better re-use the logic inside of a controller and create something like Unix output and/or formatting command such as sed, awk, sort, etc. Being able to pipe one controller into another is an extremely powerful programming concept. Even better is that they actively encourage this methodology and say that the performance is good.
Routing works very closely with your controllers as you’ll deal with it both in the form of annotations and the routing configuration files. One of the things I like about this is you’ll define “slugs” or these fragments on the URL that become part of the action method’s signature. For instance, if you had a URL such as /blog/2012/10/14/my-awesome-test-blog, then everything proceeding /blog can become a parameter in your action method that you can manipulate. It’s a pretty elegant manner to extract values from your URL structure and Symfony 2 is even intelligent enough to match those slug names against the variables you use on your action method’s signature. So ordering won’t matter (even though it should from an organizational point of view).
Lastly, there’s the Doctrine model mechanism. Before I selected it, I decided to do a Doctrine vs Propel search to see what people said between the two. It felt as though most favored Doctrine as the model mechanism because it had a higher level of activity (although Propel started becoming active again). I’m not a huge fan of the Active Record style which is what Propel is said to be. However, someone mentioned that Doctrine is very Hibernate-like and after reading how Doctrine works, it felt like the better choice for me.
The way Doctrine is handled here is that you can use several methods to define the relationships that between your database and the object. Part of it is convention based but you can also use YAML and annotations. I tend to prefer annotations overall because I like the idea of keeping everything together. Also, annotations are almost a self-documenting method for programming. The way you define a column, although exposing your database infrastructure slightly, still is very intuitive for people who may eventually take over your code. For instance, you can have something like:
/** * * @ORM\Column(type="string", length=150) */ protected $name;
As a programmer, this annotation tells me a lot about what $name is and what it ought to be on its own. The only other thing that I might want is a description of what the variable could represent.
So that’s where I’m at with the book. Somethings I’m very much looking forward to are moving towards forms, validations, unit testing and other advanced concepts. I really am interested to see how Symfony 2 can integrate with things like jquery, CoffeeScript, Less and other system level pieces such as Facebook Connect, Twitter, etc. But so far I really like what I see.
Leave a Reply
You must be logged in to post a comment.