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 %}
Tag: php framework
Okay, so Sensio Lab’s Symfony is great, but those repositories are a bit limiting in their design scope. I mean, how often do you need to access data through custom database queries and other cross referencing between database tables and not only use one table? Of course, you’re going to have to combine database tables in even mildly complex website but Symfony’s repositories are designed to deal with one table and one “entity” referencing that table.
One way to make sure you are accessing other repositories from an entity’s repository is to overload the parent’s constructor by calling on the parent constructor first. I actually stumbled onto this solution because I wanted to see what Symfony’s base Repository class’s constructor looked like. Look familiar? It passes in the entity manager ($em) and the repository’s class ($class).
protected $yourEntityRepo;
function __construct($em, $class){
parent::__construct($em, $class);
$this->yourEntityRepo=$this->getManager()->getRepository(YourBundle:YourEntity');
}Connect as many repositories as you need to this way. Keep in mind that without the parent __construct params, you can still access the entity manager and get the repositories with $this->getManager(), this is just a convenient way to do it automatically and make other repositories available within the repository if you make those repositories class variables which would then be available in any method in the repository.
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!
Besides making sure your server is running PHP 5.4 or higher, after updating from Symfony 2.3 to 2.6.3, I had to roll back a few dependency packages I found were conflicting and weren’t tested and cleared to work with the newest version of Symfony. Some of the latest compatibility requirements are found here. The latest compatibility issues can be found here.
However, the only thing I found to break was something silly and small that never should have been part of my older Symfony project and that had to do with my routes’ controllers. On occasion, I included “Action” after the method name in the controller declaration and Symfony was okay with it and it’d find the method it knew I meant to use.
However, upon upgrading to Symfony 2.6, the controller methods declared in routes looked for an “ActionAction”, meaning Symfony added the word “Action” at the end of the controller name. No where in the docs did it ever say to add “Action” anyway, it was an oversight on my part that this newest version of Symfony does not allow. So, check your routes to make sure you leave out “Action” at the end of the method name for the controller method the route is supposed to send the session to or you’ll get an error.
– Aaron Belchamber