Eat my monkeydust

Introduction

Well, I’m not actually going to answer that question because there are many thousands of projects and I don’t actually know how well they are all documented, so it would be completely unfair of me! However, with the release of this year’s advent calendar symfony is at least setting a high standard for others to follow.

So what should you read?

In our office, we have several symfony books kicking around, and new developers often ask where to start. In fact, it can be quite frustrating to have to tell a new guy that the 2 days they’ve spent studying the “Definitive guide to symfony” has really only helped them to maintain our first project from 2 years ago…

Starting a new project & don’t know much about symfony

• Do the Jobeet tutorial – seriously, no matter how much you think you can wing it, don’t. Set aside a couple of days and go through it. It’s even supported by an svn repository so you don’t have to type much code if you don’t want to – although be aware that the documentation is much more up to date that the code behind it, so if in doubt, trust the doc. The tutorial is also available in the Propel flavour.
• Scan the reference guide - I’m not saying read it, unless you have bags of time, but at least give it a quick scan so you know what’s there. When you’re struggling later you’ll think “I’ve seen that somewhere” – and chances are it was in the reference guide

Know the basics and want to take it further

• Read the forms book - The newer versions of symfony still support the forms framework and chances are you will want to use it, so it’s a good idea to give this a read. You will have a good idea already after doing the  Jobeet tutorial but there are things you will have missed and this will open your eyes.
• Read More with symfony (the 2009 advent calendar) - If you’ve started to get the hang of things and want to know what “the experts” do when they are coding with symfony, this is where to look! This book has been written by members of the symfony community, so comes totally from the perspective of experienced developers who have been through the same process as the one you are going through.
• Browse the cookbook – If there is something you are wondering about that seems like it would be a common task, there might well be a “recipe” for that very task! The cookbook has not made it to the 1.4 branch of documentation at the time of writing, but most of the recipes (if not all) will work just fine in the later versions. 
• Check the wiki - this is basically a cookbook with user supplied recipies, whereas the “official” cookbook is maintained by the core team. That’s not to say it’s any less of a resource – just that it’s slightly more likely to contain “opinions” and out of date ideas.

Stuck with something

• Check through all of the above – in particular the reference guide and cookbook. “Googling” for a well structured phrase will often get you to one of the correct pages in the manual – just be sure to switch it to the correct version, as a lot of the old 1.0 pages still come up first in searches.
• Browse the API documentation - The symfony codebase is generally very well commented, so if you are wondering about the methods of a particular class, or the options for a widget, or some other property/function/value that you can’t find anywhere in the documentation, there is a good chance the api docs will help you out.

Getting “human” help

Sometimes all the reading and googling gets you nowhere and you can quickly find yourself feeling very frustrated and alone. Fortunately symfony is backed by an enourmous community, and in a rare web-community-twist it’s one that works both ways. Not only do people ask questions, but there are hundreds of people around to answer them too!

My personal “hangouts”

• IRC – Need a quick answer, this is the place.  You won’t always get a quick answer, because there are a lot of lurkers, but there are also a lot of “regulars” who hang around in there so be patient and try again a bit later if you don’t get a response straight away. Check out freenode channel #symfony (I’m rooster).
• Symfony forum - Not quite as well publicised as the Google groups, but a valuable resource all the same. It’s really down to your communication preferences if you like forums or mailing lists, so just pick one (or both). What you will find is that different people are active on the forum compared to the Google group – it’s a shame there is not much harmony here as it can be a bit strange for newcomers. One thing I will say about the forum is that you will always get a response, if not by anyone else at least by Halfer, Ryan or myself (Russ).
• Google symfony users group - Very busy but with a lot of experienced developers around to answer questions. Can take a bit longer than the forum to get a response, but you are generally speaking to a larger audience here. You are more likely to get a response from Fabien if you post here, he hasn’t posted in the forum for 6 months! I’m RussMonkey in this one.
• Trac - If you have to come to the conclusion that what you are working with is a bug, or maybe it took you way to long to find the answer because the documentation on the subject was wrong, missing or just bad, then please raise a ticket. Depending on the nature of the issue, it can seem like it takes a while to get a response – so rather than “bumping” comments in the ticket itself, it’s normally best to start a discussion in an appropriate place, most likely the dev mailing list and be sure to link to the discussion from the ticket, and link to the ticket in the discussion.

Staying “fresh”

It’s quite hard to keep up with everything that’s going on, so there are a few things that you really should do:

• Subsribe to the symfony project blog - this is where you’ll get the most important news about changes and future development from the core team.
• Subscribe to the symfony bloggers feed – blog posts from the community, including this one, appear here. It has grown quite substantially lately, and can get cluttered with non-English blogs, which really should be in a seperate feed to be honest – but if you are using a feed reader you can just skip over them (unless you can read that particular language of course). There are a lot of experienced bloggers here, and you’ll start to recognise some of the more useful ones as you read.
• Subscribe to the user group mailing list - either as a daily digest, or an rss feed (my preference). It’s useful to scan through and see what people are talking about, so you can recognise recurring problems and issues that you may face one day.
• Those above things should take no more than a few minutes a day to browse and keep an eye on, but if you really want to get a bit more involved and have a bit more time to spare, then consider IRC, the forum and the dev mailing list also. 

Summary

So, you can see why I am starting to believe that symfony is at least one of the best documented and supported projects out there, in this post alone I have listed 14 resources that the developer can use can make the most of their time developing. Symfony has a (somewhat improving) reputation for being a one man show when it comes to the direction of the project and the core coding, but that is certainly not the case when it comes to the community support side of things – you are not alone!

I just read an extremely interesting post which explains an unwanted side effect of garbage collection by some Debian based systems. This cleanup process causes (maybe amongst other things) sessions to be cleared every 24 minutes, regardless of any ini setting you have set after the php.ini file is parsed (for example using ini_set() – if you are a symfony user, this is done during initialisation based on a setting in your factories.yml file).

Check it out: http://elephpants.blog.linpro.no/2009/10/02/unwanted-end-of-sessions/

Background

This issue has come up many times in the symfony forum and on IRC, and whilst it seems like a fairly trivial one, it is important to discuss the best practice around it. Often we want to modify a form based on something outside the form’s scope, like a user’s credentials or the page they are on, or maybe some session values – lets take the example of a dropdown widget where admin users get to see a few more options.

The bad way

Everyone that has been using symfony for a while is aware of the context singleton. This magic sprite allows us to grab all sorts of information about the context we are in, including the user, session, request, view, and many more things. Whilst it certainly has its place, most of the time, however, we should avoid using it. The clue to the reason why is carefully disguised in the class name “Context”.

When we refer to a context in our code, we are locking ourselves in to the fact that the context must exist, so every time we use it we are basically saying that this class can now only be used in a symfony project with a fully initialised symfony stack hanging over it.  This becomes a problem in things like unit tests, where you have to mock up a loaded context object with bells and whistles in order to test a simple function or class.

So this is what you might think of doing:

// In your form class
public function configure()
{
  $choices = array(1 => "something boring", 2 => "something dull");
 
  $currentUser = sfContext::getInstance()->getUser();
 
  if ($currentUser->isAuthenticated() && $currentUser->hasCredential("admin"))
  {
    $choices += array(5 => "something cool", 6 => "something leet");
  }
 
  // ....
}

The reason this is bad is that the forms framework is a standalone framework – it should be possible to pick up your form class and drop it into any project. It should also be possible to test it independently of symfony, without being tied in by sfContext. So what is the better way?

The dependency injection approach

You might read that and think “woah, this is getting complicated!” but we’re not talking about dependency injection containers here, we’re simply saying that you can make your form object depend on something to run. The thing it depends on should not be the context singleton, it should be the minimum thing that the form needs to operate correctly – which in this case, is a user object that supports credentials.

// In your actions.class.php
$this->form = new myForm(array(), array("currentUser" => $this->getUser()));
 
// In your form class
 
// ...
if (!is_object($this->getOption("currentUser")) || !($this->getOption("currentUser") instanceof sfUser))
{
  throw new InvalidArgumentException("You must pass a user object as an option to this form!);
}

The test here is where we are making this form “dependent” on a user object. In this case we are insisting that the object is an instance of sfUser, which you may argue is tying us in to symfony again, but you could use any test here to ensure that the object will have the necessary functionality you need, maybe check for the existence of a “hasCredential()” method for example.

When writing a test for this form class, we now only need to instantiate a user object and load it with some credentials – much easier than doing the same thing and locking into a context singleton. There may be other times when this form could be useful in a lightweight environment, where you can get speedy access to a user object but don’t want the overhead of the symfony context – you might not think of one now, but it’s best to code this way and you’ll have less reasons to kick yourself further down the line.

The completed code, for our single widget form

// In your form class
public function configure()
{
  if (!is_object($this->getOption("currentUser")) || !($this->getOption("currentUser") instanceof sfUser))
  {
    throw new InvalidArgumentException("You must pass a user object as an option to this form!");
  }
  else
  {
    $currentUser = $this->getOption("currentUser");
  }
  $choices = array(1 => "something boring", 2 => "something dull");
 
  if ($currentUser->isAuthenticated() && $currentUser->hasCredential("admin"))
  {
    $choices += array(5 => "something cool", 6 => "something leet");
  }
 
  $this->widgetSchema['my_dropdown']    = new sfWidgetFormChoice(array("choices" => $choices));
  $this->validatorSchema['my_dropdown'] = new sfValidatorChoice(array("choices" => array_keys($choices)));
}

Wrap up

Think about this example the next time you think about modifying a query based on a user object, or session value in a peer class, or Doctrine table class… Maybe you should have passed a parameter there too? Every class and method you write, think about how you can reuse it, will it even be possible the way you have written it? If something simply must be coded in a symfony specific way, think about making a parent and a child class for the problem you are trying to solve. In the parent class, you can make things as generic as possible – so you can re-use that class to your heart’s content. In the child class, you can add the symfony specific code – kept to a minimum.

These are mistakes anyone can make, as proved by our team of experienced developers who only came across these late into a project – after developing with Doctrine for over 6 months.

Cascading / Transitive persistence

In Doctrine there are two ways to define a cascade, one will tell Doctrine what to do, the other defines how that condition is set up on your database when Doctrine builds the sql commands. The reason this was a gotcha for me, is that we only ever used one of the types, and were completely unaware of the other one! The Doctrine manual is quite long, and unless you’ve read it several times cover to cover it’s easy to miss these things – although next time I will at least be reading the appropriate section of the manual, regardless of what I think I already know.

So, you want a delete cascade? You might do something like this in your yaml file:

PhoneNumber:
  columns:
    user_id:
      type: integer
  relations:
    User:
      class:       User
      local:       user_id
      foreign:     id
      onDelete:    CASCADE

What the above definition says is that this phone number is connected to a user, and if the user record is deleted – in order to maintain database integrity with foreign keys, the corresponding phone number records should also be deleted. This is perfect behaviour – but Doctrine does not do anything with it, it simply sets up the database to handle it, so if you are using a dbms that supports delete cascades then everything will be handled at the database level.

Adding softDelete to the equation

So here comes the gotcha, all of our tables use the softDelete behaviour – which means that instead of the row being deleted, a flag is set (deleted=true) which then magically makes the row appear deleted in all your queries (Providing you have dql callbacks turned on). This means that the row is never actually deleted at the databse level, and thus the cascade is never applied. Now I always knew this, I mean I wouldn’t install a behaviour before knowing what it does right? What I wrongly assumed was that the call to onDelete: CASCADE would take care of “soft deleting” my relations too, but it doesn’t, in fact that line is effectively useless when combined with softDelete. For that you need to set the doctrine cascade parameter:

PhoneNumber:
  actAs: [softDelete]
  columns:
    user_id:
      type: integer
  relations:
    User:
      class:       User
      local:       user_id
      foreign:     id
      foreignType: one
      cascade:     [delete]

Now the behaviour will be as expected. If you are using softDelete and your application has a lot of delete operations, you should take some time to understand what is happening, because Doctrine must fetch and load all of the related objects and then check their relations and cascade settings and so on, so in a large system deleting a single user could result in quite a lot of database queries and cpu time. It is for this reason that database level cascades are preferable, so maybe being more picky about which models you apply the softDelete behaviour would be prudent. Learn more about Doctrine Transitive Persistance.

Defining types of foreign key relations

This one is also one of those “read the manual” situations, but similarly to the above example what caught us out here is that we again thought that there was only one option for defining what we wanted to do, when in fact there were too parameters we should have been considering. This gotcha also only applies if you are defining your relations in a yaml file, as the problem lies in its interpretation when Doctrine builds the base classes.

Look at the following example:

User:
  columns:
    id:
      type: integer
      notnull: true
  relations:
    Payment:
      class:       Payment
      local:       id
      foreign:     user_id
      foreignType: many

The intention was that a user could have multiple payments, and it seemed to make sense to define it using the foreignType parameter above, however when the model was built – this always resulted in a $this->hasOne(…) statement being created, because what was actually happening is that we were not defining the relationship at the other end, we were actually defining it at the local end! So foreignType: many actually means “Many users can have one payment” – hence the interpretation of $this->hasOne(..)

In actual fact using the foreignType key is mostly useless, as Doctrine “guesses” this side of the relationship. It’s only necessary if Doctrine guesses incorrectly and you need to override it, our example above should actually have been using the “type” parameter, which defines the relationship from the other perspective:

User:
  columns:
    id:
      type: integer
      notnull: true
  relations:
    Payments:
      class:    Payment
      local:    id
      foreign:  user_id
      type:     many

Adding [ foreignType: one ] to this schema declaration would have no offect, as Doctrine would guess it to be the case (in this example). The above declaration will now correctly form a $this->hasMany(…) statement in your base class. To make it easy to remember, just forget about foreignType all together unless you come across a special case where you nee it – and prepend the word “has” to the type parameter, that should give you a clue as to what you are defining.

So, with one-to-one relationships, the type parameter is unnecessary, with one-to-many you specify the type: many (Doctrine will guess the one part) and with many-to-one you also do not need to specify the type as it will be guessed based on how you’ve got the relation set up from the other model’s perspective.

Read more about relations in the Doctrine manual.

Conclusion

it’s hard to believe that after 6 months of coding a large application that currently has over 30,000 lines of code and growing we could have a schema file with several useless calls to onDelete: CASCADE and even more useless calls to foreignType. It’s even harder to believe that in the early days of the project, we simply overrode the setup methods to add the relations that we needed, when the Schema.yml file failed to come up with the goods. Next time I think I’ll spend a little more time with the documentation, although we are of course experts now – so maybe next time we won’t need to?

If you use PHP and have ever wondered why you get something so cool for free, maybe a little tang of guilt can creep in. Contributing to the language in one way or another is a great way to pay something back, and there are many ways to do so, one of which is to write tests….

Tests keep the code sane. Every time things change, the tests can be run to make sure that everything still works ok – just like the php tests you (hopefully) write in your own projects. The best way to maintain this stability for the language itself is also to have as much code covered by tests as possible.

Every year, the PHP team organises TestFest, aiming to introduce testing to the masses in the most straightforward way. All you have to do is find out where your nearest event is being held and sign up. You will be given everything you need and assisted in every way to help you write at least one test – hopefully many more.

Details of TestFest 2009 Norway have just been released, if you are in the area, check it out!