Rendering a TWIG template without a header in Symfony is a task you’ll end up doing in your projects. You may also capture TWIG renders into strings before they get sent to the screen. If you render templates normally with the “render” method, you’ll see the headers output to your screen like so:

HTTP/1.0 200 OK Cache-Control: no-cache Date...

It’s as easy as changing “render()” to “renderView()”, this tells Symfony to skip the headers. This is handy:

... ->renderView('template'); // instead of render('template')

Sometimes you may need to modify the standard form type by customizing some of the form fields, adding form fields, changing the list of form choices, omitting certain input, and making other changes. It’s easier to alter an existing form type than duplicating it just to make a few modifications, which helps follow the DRY principle (Don’t Repeat Yourself!)

Symfony encourages, and makes it easy to stay with OOP (Object Oriented Principles) by keeping to DRY, so you not only write less code, you will have less to maintain. Not to mention your code is more reliable, which is why it is recommended to reuse form types and modify them as needed in different situations, just like you would other objects in your system.

Here are some more helpful Symfony form tips and snippets.

Set the form action inside buildForm():

public function buildForm(FormBuilderInterface $builder, array $options)
{
   $builder->setAction($path);
}

Change the forms “action” url path in the createForm():

$form = $this->createForm(new WhateverFormType(), $object, array(
          'action' => $this->generateUrl('action_route'),
));

Customize form values and attributes in the createFormBuilder():

$form = $this->createFormBuilder($task)
  ->setAction($this->generateUrl('target_route'))
  ->setMethod('POST')
  ->add('task', 'text')
  ->add('dueDate', 'date)
  ->add('save', 'submit')
  ->getForm();

From what I’ve gleaned from Symfony 2.5 documentation, repositories are best when they’re associated with a distinct entity and have a narrow use for that entity and its other related entities, these are logical associations even though all repositories are still reusable, even from other bundles.  Services are more global and easier to instantiate, not to mention that any dependencies of service objects can also be defined in the services.yml file so the Entity Manager or some other dependent classes can also be automatically injected as needed.

Also, the Symfony documentation suggests that any actions/queries contained in repositories should only retrieve information (act as a “getter”) and not alter any data, as opposed to classes called from a service where their utility is interchangeable as database level “getters” and “setters”.  That said, if you need objects that are easily called from within the controller where you may need to alter data, the Symfony documentation is a little thin on the “best practices”.  I think it’s so much easier to call on these actions/queries in the same repositories you’ve already instanced.

For more complex form projects in the past, I have preferred putting such “form handler” objects that need to actually alter data inside a “/Handlers” folder within the bundle’s “/Forms” folder in order to mirror the organization of “/Repositories” while differentiating the purposes of each, just to follow the “best practices” recommended by our friends at Sensio Labs.

For example, I create a new class that might be called upon to alter certain child entities, perhaps an entity that is a collection of entities for some complex form, like so:  “/MyBundle/Forms/Handlers/MainFormHandler.php”.  Then, within this “MainFormHandler.php” class, the Entity Manager is instanced and I can then call on different methods for the purpose of inserting and updating database data.  If you are PHP developer with Symfony experience, I would love to hear your take on repositories, services, and the special “Handler” classes I mention above.

– Aaron Belchamber

Senior Web Developer
Celebrating 20 years of evolutionary marketing

If you’ve designed your database and set it up, there’s a quick way to initialize your Symfony bundle to start talking to it within a minute! Here is where using a framework to do those mundane coding tasks empowers developers to focus their time and energy creating solutions and less time focusing on creating tools and setting up an environment to create those solutions.  After all, a lot of those tools are used in one form or another for many different projects, aren’t they?

As a developer, imagine if you have to keep writing some version of PHPMyAdmin over and over again, knowing that PHPMyAdmin does a better job.  That’s where using a PHP framework starts to really put muscle in any company’s web development team.  GET THEM ON A FRAMEWORK!  You’ll be happy you did later.

If you don’t have a YML file but have a table on your database, run this command to import YML file from your database. You can filter by a single table name, but be sure to use the camelCase names since this references Symfony’s objects, which are called Entities. This actually makes sense since as a coder you need to easily distinguish your database field names which usually incorporate underscores, from the class properties that also use class methods which use camelCase.

php app/console doctrine:mapping:import YourAppBundle yml –filter="Table"

Based on an YML File this command will create a single entity for you:

php app/console doctrine:generate:entities YourAppBundle:Table –path src/

And if you want to create all entities

php app/console doctrine:mapping:import YourAppBundle yml
php app/console doctrine:generate:entities YourAppBundle