Rails is doing it, Java is doing it very similar, you can do it in symfony, too: make use of the Single Table Inheritance pattern.

Read the rest of this entry »

Let’s imagine you have a form set up and want to add some dynamic values to the object being saved by this form after the form has been submitted by the visitor.

Read the rest of this entry »

As there are many situations in which you might want to use the HTTP status code “304 - Not Modified” symfony gives you an easy way in doing so. Especially while you are delivering dynamic content, it might not be that easy to determ whether the request has been modified or not. Sending the HTTP response header is one thing, later on you have to check against the If-Modified-Since HTTP request header sent to your application.

Read the rest of this entry »

You might have thought about it - me too :) It’s one simple way to use subdomains to manage the chosen application of your symfony project.

Read the rest of this entry »

Today I have written my first unit test in symfony in which one of the models has attached a propel behavior. In my case it was the sfPropelActAsSluggableBehavior. While writing the unit test I didn’t thought it would be a problem, until I finnaly ran the test.

The error message was short, but has a lack of information. “sfPropelActAsSluggableBehavior is not registered” - sweet! So, what’s going on? The autoloader can’t find it? Anything with the ProjectConfiguration wrong? In fact, it was the sfContext which was missing. Well within an unit test this is usual, because you are - most often - testing the model and its functions. But how to test behaviors of the model? You need to get the sfContext initialized, which is quite simple and you go on with the testing.

<?php
 
require_once(dirname(__FILE__) . '/../bootstrap/unit.php');
 
$limeTest = new lime_test(20, new lime_output_color());
 
$limeTest->info('Setting up sfContext ..');
sfContext::createInstance(ProjectConfiguration::getApplicationConfiguration('nopaste', 'test', true));

So after bootstrapping the unit test you got your ProjectConfiguration set up. What you need now is an ApplicationConfiguration. Well it’s not that good, because you add a dependency to your models test, but I found no other way to get the test running, except removing the behavior itself. Create the sfContext with a test application and your test will run!