We now have 50 fake BlogPost entities in the database, a way to view them (via listAction), and a way to create more new BlogPost entities (via the createAction).

In order to be able to create new BlogPost entities we had to create a simple Symfony form which allowed us to post in new data.

To edit data, the good news is that we can re-use the existing form. All we need to do this time is pass in an existing BlogPost entity whilst creating the form, and Symfony's form component will re-populate the form with our existing data.

We can simplify things even further by allowing Symfony to inspect the URL, grab the passed in id, query for a BlogPost with that ID, and then make the resulting BlogPost entity available for us through dependency injection.

It all sounds quite complicated when written like this, so let's quickly see that in action:

// /src/AppBundle/Controller/BlogPostsController.php

     * @param Request  $request
     * @param BlogPost $blogPost
     * @return \Symfony\Component\HttpFoundation\RedirectResponse|\Symfony\Component\HttpFoundation\Response
     * @Route("/edit/{blogPost}", name="edit")
    public function editAction(Request $request, BlogPost $blogPost)
        $form = $this->createForm(BlogPostType::class, $blogPost);


        if ($form->isSubmitted() && $form->isValid()) {
            // * etc *

        return $this->render('BlogPosts/edit.html.twig', [
            'form' => $form->createView()

In the Route we can see the {blogPost} parameter.

To call this route, we could make a request in our browser to GET http://our-symfony-3-site.dev/app_dev.php/edit/16.

In this example, Symfony would see that we passed in 16 as our {blogPost} parameter.

Before the editAction would be called, an event listener would hear of this request, and then query Doctrine for the BlogPost entity that matches id: 16.

Then, it would pass the resulting entity on to our editAction, injecting it for us directly in to the method. Pretty awesome. We don't need to do anything to make this work, other than follow this convention.

Also, because Doctrine is already managing this entity, we do not need to call persist when later wanting to save changes to the entity. We only need to call flush.

If any of this is new to you, or you don't feel entirely comfortable with it, then be sure to watch this series where creating, saving, updating, and deleting inside Doctrine are all covered in more depth.

Code For This Episode

Get the code for this episode.

Share This Episode

If you have found this video helpful, please consider sharing. I really appreciate it.

Episodes in this series

# Title Duration
1 Intro with Twig CRUD - List 06:03
2 Twig CRUD - Create 03:25
3 Twig CRUD - Update (Edit) 02:43
4 Twig CRUD - Delete 02:36
5 Simple Symfony 3 RESTful API Setup 05:32
6 API - GET a Single BlogPost 04:51
7 API - GET a Collection of BlogPosts 02:20
8 API - POST to Create New Data 06:30
9 API - PUT and PATCH to Update 04:11
10 API - DELETE 03:34
11 Angular - Setup, Styling, and GET All 09:19
12 Angular - Refactoring 10:23
13 Angular - Create (POST) 06:54
14 Angular - Update (PUT) 08:41
15 Angular - Remove (DELETE) 06:44
16 React - Intro, Setup, and GET all 06:54
17 React - Refactoring 09:14
18 React Router 04:41
19 React - Create (POST) 13:13
20 React - Update (PUT / PATCH) 12:40
21 React - Delete 11:00
22 React - Tidy Up, and Finish 04:14