Symfony2 Best Practices resume

Today I come across this Best practices in Symfony PDF:

And I though about my own practices and where to apply some of this seen in the Best practices book.

Here is a brief 3 points summary of things I would like to change in my next projects:

  1. Using Constant instead of variables in parameters.yml for those settings that rarely (or never) change
    // src/AppBundle/Entity/Post.php

    namespace AppBundle\Entity;
    class Post {
    const NUM_ITEMS = 10;

    As pointed  in the book, doing so, the benefit is that you can access this constant from almost anywhere in your application. Including your twig templates. This is exactly the part I was not aware of:
    // src/AppBundle/Resources/views/Controller/mytwigtemplate.html.twig

    Displaying the {{ constant (‘NUM_ITEMS’ , post ) }} most recent results.
  2. Keep your controllers Thin

    Symfony follows the philosophy of “thin controllers and fat models”. This means that controllers should hold just the thin layer of glue-code needed to coordinate the different parts of the application. As a rule of thumb, you should follow the 5-10-20 rule, where controllers should only define 5 variablesor less, contain 10 actions or less and include 20 lines of code or less in each action. This isn’t an exact science, but it should help you realize when code should be refactored out of the controller and into a service.

    That’s an easy to remember Rule:
    5   Variables or less
    10 Actions (Calls to services / Forms validation, etc)
    20 Lines of code

    Storing hundred of lines for an Action is always a bad idea specially if you are not the only one working for the project.  And it mostly denotes some bad architectural start, since I can imagine that a controller Action has so many lines has parts that are common and can be reused in another actions. So why not to put all related actions in a service ?

    In this same Chapter, has a best practice that I consider really important, and is in my point of view how an ideal Symfony oriented project should be thought:
    You should aggressively decouple your business logic from the framework while, at the same time, aggressively coupling your controllers and routing to the framework in order to get the
    most out of Symfony

  3. Use eventListeners.
    As an example: Pre and Post Hooks
    If you need to execute some code before or after the execution of your controllers, you can use the EventDispatcher component to set up before/after filters

I find eventListeners one of the most cooles features. They are many use-cases, for example OneUp Uploader bundle uses it to handle File uploads, calling an event listener each time a file is uploaded through Ajax. Like that you can find many real use cases to do this kind of automatic things in the background.

If you like any other interesting part of this Symfony Best practices Book, feel free to join the conversation

Symfony Form EventListeners

Frequently when coding forms, there is a constraint or a field that becomes *required depending on the value of a select field. For this and many more user cases, symfony has the Form Event Listeners that are design specifically for that cases.

So if you want to do get the Request in the form to inject it in some custom Constraint, then this is the incorrect way to do it:

public function buildForm(FormBuilderInterface $builder, array $options) {

$request = Request::createFromGlobals();
$request = $request->request->get('MyBundle');
$type = is_null($request['type']) ? $options['data']->getType() : $request['type'];

$builder->add('myDate', 'datetime', array(
'constraint' => array ( new fieldConstraint (array('type' => $type )) )


The Symfony approach using Form event listeners looks more like:

<pre>    public function onPreSubmit(FormEvent $event)
        $form = $event->getForm();
        $data = $event->getData();
// Note that at this point $data comes from POST
        if ($data['type'] === 'sometype') {
// Then we re-declare the form element adding the constraint (And any other needed stuff)
            $form->add('myDate', 'datetime',
                    'constraints' => array(
                        new fieldConstraint()

This looks at least more elegant and readable than trying to access the Request from the formType itself.

And the lesson learnt is:
If you feel that you are trying to access a value in a strange, non straight-forward way, then stop and take some time to research. For sure there is an easier way to do it ;)

Sonata-page Bundle CMS

At this point I was going to make a full stop and try to make a step by step installation, that is easy to configure and also self-understandable. But I come to the point of so much trial and error, apart of learning all the command-line stuff and reading installation procedures, that there is no point in stuffing around with Sonata Admin / Users / Pages Bundles if you don’t have the basics right.

So I will leave the SymfonyBaseAdmin as clean as possible, but anyone that wants to try to install it, will have to mess around and have some patience in order to make it work.

In this latest commit, I left the doctrine Orm settings with auto_mapping: true
That is something the Doctrine purist won’t like it so much, but it let’s you mess around adding/removing Bundles from the Symfony AppKernel.php without breaking the Doctrine:schema:update command line option to update the Tables. Now you can add or remove the sonata-page and sonata-user Bundles without messing with the config.yml every time.

One thing I noted after installing the Page Bundle, is that is quite useless without the User bundle, since is all tied up in the Admin area to work together. So at the end I installed and setted up the User Bundle too. I’m leaving the things separated in the config.yml file, so if you don’t need them simply comment or remove the :

  – { resource: sonata-page.yml }
– { resource: sonata-user.yml }

And their respective lines in the Symfony AppKernel

That said, it’s essential to read the Sonata Users and Pages documentation to play around with this.

After running the composer.phar to get all the required vendors, do not forget to run:

app/console sonata:easy-extends:generate SonataPageBundle –dest=”./src”

app/console sonata:easy-extends:generate SonataUserBundle –dest=”./src”

app/console doctrine:schema:update –force

And last step, generate an Admin user for the administration area:

app/console fos:user:create admin –super-admin


There is another nifty detail that drove me crazy for some minutes, and is that the way that pages work, require that every time you update something is essential to make a new “snapshot” of the site.
So if you publish a set of pages, there won’t be seen by the router, until going to Site Admin and hitting the Create Snapshot button. That is something that I find quite annoying, but it shouldn’t be so hard to workaround.

After playing for about two days with the Page Bundle I can feel that is a powerful component to build your own pages. In no way is meant to act as a “client ready” CMS, it looks more like a straight “developer” tool, but of course with some heavy customization it will become some interesting addition to any project.

This days, while I keep on with my Sonata self-learning project, I’m hearing quite a lot of cool electronic music.
Along with some Berlin based independant artists, posting some playlists afterwards…

Crud in 5 minutes per Table using Sonata and Doctrine ORM

Create, read, update and delete is something you need to manage in any Project.

Here is simple formula that works using this simplified version of Sonata Admin and here is the list of steps to achieve a new Crud list per entity:

  1. Design your table structure or pick an existing one
  2. Use Doctrine to create your Entity Classes from the Tables
  3. Add an admin service in Sonata to bring up the Crud functionality

Expanding the points above:

#2 Converting existing mySql tables in Doctrine Entities
After adding your mySql database credentials to app/config.yml, having existing table structures / data, run the following command in the project root:
php app/console doctrine:mapping:import –force yourSymfonyBundle xml

This will generate ORM mapping schema information as xml in the directory Resources/config/doctrine that will be used with the next command to generate the Doctrine entities in the Synfony Entity folder.

This is to create the Tables when you have the entities written:
php app/console doctrine:schema:create

For more information read the documentation regarding Symfony and Doctrine

#3 Adding the Entities in Sonata to enable the Crud functionality

namespace BaseAdmin\BaseAdminBundle\Admin;

use Sonata\AdminBundle\Admin\Admin;
use Sonata\AdminBundle\Datagrid\ListMapper;
use Sonata\AdminBundle\Datagrid\DatagridMapper;
use Sonata\AdminBundle\Form\FormMapper;

class CityAdmin extends Admin
    // Fields to be shown on create/edit forms
    protected function configureFormFields(FormMapper $formMapper)
            ->add('city', 'text', array('label' => 'City'))
            ->add('name') //if no type is specified, SonataAdminBundle tries to guess it

    // Fields to be shown on Filter forms (right)
    protected function configureDatagridFilters(DatagridMapper $datagridMapper)

    // Fields to be shown on Datagrid lists
    protected function configureListFields(ListMapper $listMapper)

basicAdmin Entities list

basicAdmin Crud List


The code to achieve this is Open source and the repository is located here:

Symfony Base Admin. New project

At the end of April 2014 I wanted to start testing Symfony taking a base project that was already done in Bonfire/ Codeigniter.

Now the time has come, and I’ve been working with Symfony for about 3 months, so I have more MVC knowledge with the framework. At the same time I was searching for something that was similar as Bonfire to start an easy Admin Panel for some projects. I searched for two weeks but didn’t find anything similar, so no surprise there is no easy panel, you must make your own. And it’s not rocket science, so instead of complaining, let’s do it ;)

With this basic principles in mind:

  • As least components as possible, using Symfony last edition, currently 2.5.* as defined in composer.json
    If we add a new component, is because it’s used somewhere, and it’s commented along with a proper commit in the repository. The goal is that the vendors folder is clean and to to keep the starting codebase to a minimum extent.
  • An easy way to link existing SQL tables to entities, using Doctrine ORM. ( There is no import functionality as in Bonfire )
  • Use the quite well documented Sonata, to make this possible, adding the basic functionality and some examples of how to achieve CRUD functionality.
  • Twitter bootstrap in the admin and if possible also in the front-end, to keep a well designed responsive base design 

Putting this in a Public repository on github so anyone can fork it, modify it and use it for any project.


OOP Fundamentals

There are many different takes on object oriented programming. I’ve saw this video of “Uncle Bob” latest week and I wanted to write a post about the fundamentals of OOP programming.

I like the way he explains OOP, interfaces, polymorphism and other related areas of object oriented methodology. So before starting with my post series of Symfony, I wanted to review a couple of basics, and how they are supposed to be used.

The benefits of working using OOP is that the application itself becames minimal, and the modules can be coded in independant pieces, that have a decoupled arquitecture and are independantly deployed, hence repairing a certain part does not brake the others. In Symfony this modules are called bundles. A good programming example, is the Symfony components itself, and another Business Logic example I’ve seen recently with independant Bundles is Elcodi.


The formal programming concept of objects was introduced in the 1960s in Simula 67, a major revision of Simula I, a programming language designed for discrete event simulation, created by Ole-Johan Dahl and Kristen Nygaard of the Norwegian Computing Center in Oslo.  Simula introduced the notion of classes and instances or objects (as well as subclasses, virtual methods, coroutines, and discrete event simulation) as part of an explicit programming paradigm.


Encapsulation is the packing of data and functions into a single component. The features of encapsulation are supported using classes.

Inheritance is when an object or class is based on another object or class, using the same implementation or specifying implementation to maintain the same behavior (realizing an interface; inheriting behavior). It is a mechanism for code reuse and to allow independent extensions of the original software via public classes and interfaces. The relationships of objects or classes through inheritance give rise to a hierarchy.

Polymorphism is when source code dependancy is opposed to the source of control.


Symfony2 Routing cheat sheet

Symfony2 Forms cheat sheet

Symfony 2. New series of Posts coming !

It’s been quite a while I don’t post anything here.

And there is a good reason: I’m quite busy. My family comes to visit a Berlin, got a new full time job as a developer, and when I come back home I still keep on reading documentation and doing simple code examples, that I do not push anywhere because they are only learning sh!ts so far.

But soon I’m planning to release some stuff and maybe create some new sites with Symfony, that serve a purpose. But no more client work for some time, I just want to arrive home, and do other things as reading books, hearing some music or just hang around with friends. Also it’s about 3 months I’m going to a very cool Salsa class every Tuesday and Sunday. Salsakurs is now Mittlestuffe, not anymore the boring basics :)

One of the most interesting books I read so far, and still re-reading it when I want to apply some stuff is “A Year with Symfony” . A name that honours the labour, since it’s only 3 months I started learning the framework and I still feel that I know only 10% of it.

So I wish you all a good, sunny and entertaining Summer!


Neues Projekt: Codeigniter wegen Symfony 2

Ich habe noch 1 Woche Zeit. Die Aufgabe ist, diese kleine MVC Projekt:

In Codeigniter MVC, nach Symfony 2 MVC framework Weiterentwicklung

Dann Ich freue ich mich sowohl in Bezug auf die Frameworks vergleichen in Hinsicht auf:

  • Geschwindigkeit
  • Struktur und Data Models
  • und wie schwer ist es, eine Admin-Panel zu Entwickeln
    (and how hard is to code an admin panel, in case my german is not so clear)


How to add Bonfire to an existing Codeigniter framework project

MISSION: Integrate simple codeigniter project
with bonfire powerfull HMVC modules and administration access.

Step 1

Copy application and bonfire folders into project root.


Step 2

Modify existing MY_loader class that will be overridden by Step 1 with your custom functions. In my case, I was using sparks library and the existing codeigniter theme functionality. So I left :


/* load the MX_Loader class */
require APPPATH.”third_party/MX/Loader.php”;

/* This will be class MY_Loader extends CI_Loader {}  in your Codeigniter project */

class MY_Loader extends MX_Loader {

// And copied here my custom methods.


Step 3

Routing and class names:

http:/onstage/public/index.php/event/hamburg/215  (Local test)
Fatal error: Cannot redeclare class Events in C:\xampp\htdocs\onstage\bonfire\libraries\events.php on line 33

Small fail: It seems bonfire already has a class called events. And collides with my own events controller…So I will rename it to something else and change routing accordingly.

So, we update the route:
$route['event/(:any)/(:num)'] = “eventos/lookup/$1/$2″;
And the corresponding file controllers/events.php to eventos.php . This is the beautiful part of MVC. We just changed some files and routing, but the URL call will be exactly the same. This internal changes won’t affect at all any frontend functionality.

Ok and now the latest routing update, this time in the apache virtual host, the codeigniter goes to the root. But the Bonfire default is the public directory.

With this change, so far, almost all old codeigniter project is working like before, with the added plus that now has a Bonfire administration. But we have still some routes to correct.
For example, the old city route is no longer working:

Drops a 404. But the application/config/routes.php are there :
$route['hamburg'] = “home/hamburg”;
$route['munich']    = “home/munich”;

And the home controller has those methods inside. So I yet have to find those.


The solution to my path problem was solved in two steps:

a)  First changing the application/config.php and removing the index.php page from the index_page variable:
$config['index_page'] = ”;

b)  Modifying the view paths to css / js external HTML resources, referring to step 2 since bonfire goes to /public as default:

<link rel=”stylesheet” href=”/public/css/alpha_background.css”>  So now new route will be :
<link rel=”stylesheet” href=”css/alpha_background.css”>

After this I had running in the front exactly as before, with the benefit of having a complete bonfire admin in the back-end.

I’ve posted this in the bonfire forum to see if I can get some feedback and also to share with others, since this is a completely open project where all changes will be shared on a github account where anyone can fork, edit, and comment on changes. project update

OnStage Konzerte 

Apr 12, 2014

  1. Martin

    Adding import route

  2. Martin

    Finished module import + added spark tools

Desarrollo, Investigación y nuevas Tecnologías. Buenos Aires. Berlin.


Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 500 seguidores