en venta con más de 14.900 indexadas en google está en venta en un precio estimado calculado a lo que daría el sitio en publicidad en 3 años. O sea, solo con moverlo de sitio o incluso quedandose con una copia de la instancia de Amazon AWS en la que corre, es una inversión que se recupera sola en 3 años o menos si tienen pensado hacer el sitio interesante o agregar más productos. Tiene entre 800 y 1000 visitas diarias, de los que el 90% son visitas desde España. Dentro y incluido en ese precio viene un administrador también, super rápido donde se pueden editar y agregar nuevos productos.
Interesados contactar con

Good architecture and why not to render Controllers inside Views

In Symfony, Zend and other frameworks you can rend a controller inside a view like this:

{{ render(controller('AcmeArticleBundle:Article:recentArticles', { 'max': 3 })) }}

 Creating and Using templates documentation here.

Just because there is a possibility to render(ControllerMethod,{ params}) in a template doesn’t mean you have to use it.

Doing so leads almost always to a shitty architecture, the turning point where projects start to be hard to debug, since you are mixing a VIEW (Presentation layer) with a CONTROLLER, that in turn renders another VIEW. You get the point.

What happens afterwars is a little bit counter-productive when debugging:
An error in the ControllerMethod is rendered as a template View error.   Not so nice isn’t it ?

Controller methods should Return a View that has all the required parameters to render the View. But if inside that View, you are going around the loop, rendering another Controller that in turn has another View, can be the start of a infinite loop that swallows the universe and you should get a warning red light in your Frontal Lobe. Overcomplicating things with quick and dirty solutions is the wrong way in Software architecture and the responsible of a big amount of relationship problems.

I vouch for strong architecture in software projects

This cheap solutions, like using this render commodities, lead to the start of the bad. And I suggest to avoid it as much as you can unless there is no other possible way.  And certainly there is!

That is the reason to use MVC. To separate Code from Presentation layer, start mixing both, and your architecture will leak.

Symfony Bundles that come always handy for Admin Panels

After a quite accidental start with the Framework I’m enjoying a lot developing stuff with their Form component.
Using bootstrap and almost without any front-end javascript one can build great Admin-dashboard forms, using only a :
{{ form_start(form) }}
{{ form_end(form) }}

Where you want the form to be rendered in the twig template.

As one of my jobs is building friendly Admin Panels, I started to realize that apart of some custom tailored-made solutions, frecuently there is a ground base that works for almost any CMS or CRUD (CReate, Update , Delete manager)

So instead of googling and fetching them one by one, you can find them, or comment them in this post:

  1. TinymceBundle
    Great one.  After installing it, you have a ready made
    {{ tinymce_init() }}
    to put at the end of your twig template. All what you need to do is adjust the config and add a “tinymce” class in your FormTypes.
    Alone with that you can build a CMS in some minutes.
    How cool is that ?
  2. KnpPaginatorBundle
    Whenever we list stuff and becomes large, we need to paginate. This one comes really handy. And like almost all the KNP bundles, is a really nice piece of code, and developer friendly.
  3. Bootstrap-bundle
    Bootstrap is the state of the art front-end to deploy Admin Dashboards.  I had a little fight before making this one work in my Linux dev machine, but is just because I’m not a very front-end guy at the moment, and didn’t had this CSS tools to compile things.  Actually you don’t need this if you want bootstrap base, but I though that having it in a Bundle and thus, being able to install it by composer was a cool thing. And it is!

And that’s basically the 3 things I mostly use all the time.
There are hundreds more, but the basic, ground structur is there.  Making a login / password with FOS User Bundle is also very easy.

In the beginning, the first 2 months or so I was looking towards something that creates an Automatic CRUD manager from a mysql table. After learning more Symfony, I realized that you don’t really need something like that, when it’s quite easy to create your Entities from an existing mysql DB and after that make some Form types and base templates. Cannot get more simplified!
Of course will take some effort, but at the end, you have a custom tailored panel with validation at the top where you can add the customization on top to make your Dashboard more usable.
Hopefully you will make your client happier as well.

Composer lines to add this:

require: {
"stfalcon/tinymce-bundle": "dev-master",
"knplabs/knp-paginator-bundle": "dev-master",
"braincrafted/bootstrap-bundle": "~2.0",
"twbs/bootstrap": "3.0.*",
"jquery/jquery":  "2.1.3"

Symfony heads up

In the latest 6 months I’ve been quite busy learning Symfony, while I ended up partly in stackoverflow, at the beginning searching for answers to my questions and then when I learned how to solve them giving some answers myself.

Now finally I’m at the point where I can code an admin web panel or CMS completely with the framework. And at the same time, more I learn, I discover how much I don’t know. That’s why next year I’m planning to get certified and invest some time and money going to some workshops.

Matthias Noback, author of the book “1 year with Symfony”, is giving on the beginning of 2015 a special training called Hexagonal Symfony.

If you are interested in his training just sign up in the newsletter to check if he is giving the training near your city. For sure it will be a great heads up in your Symfony work.

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 ;)

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 526 seguidores