The Express Support for Projects Built on the Symfony2 Framework
Have you ever been - as a software developer - into the uneasy situations when you need to support projects built with frameworks or technologies unfamiliar to you? Most developers try to avoid such situations fearing the headaches they usually cause. But hey, isn’t it a part of an engineer’s job - to dig into and understand new systems?
A project built on Symfony2 was such a story for myself, so let me share some tips on how to provide an express support for projects built on the Symfony2 framework.
The first acquaintance
Symfony is a free full-stack PHP web application framework that also features a set of reusable PHP libraries handy for solving regular web development problems. So, you can use it both as a full-stack framework and use it to build a project from scratch, or use only some of its components according to your current needs.
However, when you’re dealing with in-development or ready-made projects built on Symfony2, the first thing I’d suggest doing is running tests. Comprehensive tests will help you understand how things are organized in the project and expose ole nuances of the project’s code. It may appear that you don’t need to rewrite the bulk of the project - even small calibrations might be quite enough and save you a lot of time.
Database models and how to work with them
Symfony2 uses Doctrine and Propel as the ORM (object-relational mapping) libraries. In this article, I speak about the Doctrine2 use case.
For the describing the entities your project works with, Symfony2 employs the Entity classes. Thanks to the tight integration with Doctrine2, working with entities is a pure pleasure: you can operate big sets of data and connect them in the way you need. In this case, the corresponding data will be stored in a database, and all connections needed for maintaining the data integrity will be transferred as well.
The command line
php app/console doctrine:generate:entities
helps create the default getters and setters for all configs.
Here’s an example of a simple model with a setter and a getter:
<?php
namespace AppBundle\Entity;
use Doctrine\ORM\Mapping as ORM;
/**
* Test.
*
* @ORM\Table(name="test")
* @ORM\Entity(repositoryClass="AppBundle\Repository\TestRepository")
*/
class Test
{
/**
* @var int
*
* @ORM\Column(name="id", type="integer")
* @ORM\Id
* @ORM\GeneratedValue(strategy="AUTO")
*/
private $id = 0;
/**
* @var string
*
* @ORM\Column(name="name", type="string", length=100)
*/
private $name;
/**
* Get id.
*
* @return int
*/
public function getId()
{
return $this->id;
}
/**
* Set name.
*
* @param string $name
*
* @return Test
*/
public function setName($name)
{
$this->name = $name;
return $this;
}
/**
* Get name.
*
* @return string
*/
public function getName()
{
return $this->name;
}
}Creating and using different entities, you should keep in mind the queries that will be sent to the database: the faster the queries will be processed, the faster your services, APIs, and the application itself will work. That’s why, you should use the EntityRepository class, basically a repository for storing all the entities you will work with.
For queries, you can use either the simple findBy and findOneBy methods, or create your own queries and optimize them using the QueryBuilder.
In case you have forgotten any parameters while creating entities or want to add some new ones, you should use the migration bundle.
And here are some useful commands for this:
php app/console doctrine:migrations:diff
- this command launches the checking process scanning for differences in entities and creating a migration file.
php app/console doctrine:migrations:migrate
- this command allows you to apply the migrations not applied to the project yet.
How to call and display a controller
Symfony2 follows the MVC (Model–view–controller) pattern, so you can easily track the dependencies concerning which controllers, views, and models, as well as their use cases.
Let’s start with controllers.
Find the routing.yml file in your project (app/config/routing.yml), and you’ll be able to find another routing.yml files that can be called in the project and the controllers your app is using when active. Due to the Symfony coding standards, all controllers are being stored in the Controller folder and, correspondingly, all files’ names in it end with ‘Controller’.
Each controller contains actions (for example, indexAction) that are being called depending on the address defined in the @Route annotation. Route shows the address assigned to the action and can contain info about all parameters that are being received and the query type.
There are also existing bundles (for example, FOSRestBundle) that make working with controllers simpler depending on the goals they are used for.
During the action’s work, a view can be generated. You can find all your views in Resources/views. Most often, views in Symfony2 are presented as Twig code. While working with views, be careful with connecting other view templates - it can be confusing when unexpected elements suddenly appear on a page.
It works while you rest
There can be cases when you need to implement a logic that will automate certain actions like sending notifications to all or some particular users of the app. You can achieve that by creating a command. You can describe your own set of commands and the parameters applied to them.
Using the command:
php app/console list
you can see the comprehensive list of commands that are available at the moment. When you generate a new command, it will appear in this list, too.
Here’s how you can create a simple command:
namespace AppBundle\Command;
use Symfony\Bundle\FrameworkBundle\Command\ContainerAwareCommand;
use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;
class TestCommand extends ContainerAwareCommand
{
protected function configure()
{
$this
->setName('test')
->setDescription('test command');
}
protected function execute(InputInterface $input, OutputInterface $output)
{
$output->writeln("Test");
}
}Also, the command:
php app/console test
calls the command you have generated.
This command call can be set in the cron task, so the command would be called automatically within the predefined intervals.
These are only our basic recommendations for those who got to support projects built on the Symfony2 framework. Stay tuned to the Agilie blog for the further updates and never be afraid of experimenting and learning new things!
