Strange how obscure it is to find a clear example of how to just access or show the value of a cookie in Twig, so here it is!

{{      app.request.cookies.get('yourCookieHere')  }}

Twig is the templating engine that powers Symfony views.  Symfony is the PHP framework from Sensio Labs.

If you are a company that uses open-source software and developers and you are not using a PHP framework, you should consider migrating your legacy “cowboy” code to a collaborative, scalable framework like Symfony before it becomes a necessity for your company.  I have overseen many migrations of systems and data over the years and am available for consultation at my business consulting site at Belchamber.us.

– Aaron Belchamber


Here is a quick way to access all request variables and output them in a Symfony Twig view:

{% for request in app.request.query.all  %}
   {{ request|raw }}<br/>
{% endfor %}

 


A MySQL “tinyint” field, regardless of length, is mapped as a boolean in Symfony’s MySQL DBAL platform.  Good to know, so when you start typing in those Doctrine ORM mapping files in annotation or my preferred way, YML files, you won’t get a fatal error because you didn’t define the field properly.

Here’s a list of the other main MySQL field types and how they are defined in Doctrine ORM mapping files.  It can get a little confusing, like “timestamp” is also “datetime” even though “datetime” is “datetime”.  It is what it is.  Once you realize you’re just making translations for one system to talk to another, it gets easier!

This list is helpful because when you start converting your database table fields, you will need a reference, or better yet, look into “Skipper ORM” and it will take care of mappings and creating entities out of your database tables automatically for you!

protected function initializeDoctrineTypeMappings()
{
$this->doctrineTypeMapping = array(
'tinyint' => 'boolean',
'smallint' => 'smallint',
'mediumint' => 'integer',
'int' => 'integer',
'integer' => 'integer',
'bigint' => 'bigint',
'tinytext' => 'text',
'mediumtext' => 'text',
'longtext' => 'text',
'text' => 'text',
'varchar' => 'string',
'string' => 'string',
'char' => 'string',
'date' => 'date',
'datetime' => 'datetime',
'timestamp' => 'datetime',
'time' => 'time',
'float' => 'float',
'double' => 'float',
'real' => 'float',
'decimal' => 'decimal',
'numeric' => 'decimal',
'year' => 'date',
'longblob' => 'blob',
'blob' => 'blob',
'mediumblob' => 'blob',
'tinyblob' => 'blob',
'binary' => 'blob',
'varbinary' => 'blob',
'set' => 'simple_array',
);
}

 


In the newest versions of Symfony greater than 2.2 you can embed output from controller by calling it with this handy TWIG snippet:

{{ render(controller('PostBundle:Posts:recentPosts', { 'category': 'cool symfony tips' })) }}

Check out Sensio Lab’s documentation to learn more.

This is especially useful if you want to create a snippet that will deliver content independent of the controller you are calling the main content of the page — stuff around the periphery.  As long as you aren’t using any logic, this is an acceptable use of MVC and it decouples say content in a related widget on the page from the controller of the page’s main content.  This separation of concerns ensures the controller of the main content stays as lean and clean as possible!


At last, a framework has finally given the tilde (~) a little respect. Hash tag (#) usually gets all the glory, but not this time!  Not is in this case.  Granted, the tilde might be happy to be used at all and chances are, this obscure solution to another view issue doesn’t mean tilde’s ready for primetime, but let’s show some respect when respect is due.  After all, without the tilde, you wouldn’t be able to dynamically create field names with string concatenation.

Symfony’s TWIG uses the tilde to help dynamically address or declare form fields.  This is handy if you have a bunch of form fields with hideous serialized numbers appended to them like “field_name_1” and “field_name_2″….  Without addressing all 50 of these, you can loop through them dynamically like so.  In this example, I only loop from 0 to 4.  An added bonus?  I check if the form field name exists.  That’s helpful in case you’re receiving form fields that are dynamically added and you don’t know how many possible form fields your antiquated form made, probably through some Javascript or using JQuery.

{% for i in 0..4 %}
   {% if attribute(form,'field_name_'~i) is defined %}
       {% for formItem in attribute(form,'field_name_'~i) %}
            
            {{ form_row(formItem) }}

       {% endfor %}
  {% endif %}

{% endfor %}

The only question is…. why didn’t you just use an array for those form fields?!  field_name[0], field_name[1] is much easier, but who am I to judge?