> Symfony 6 > Doctrine, Symfony 6 & the Database
Login to bookmark this video
Buy Access to Course
16.

Flash Message & Rich vs Anemic Models

|

Share this awesome video!

|

Keep on Learning!

Start your All-Access Pass

With a Subscription, click any sentence in the script to jump to that part of the video!

Login Subscribe

After we submit a form successfully, we always redirect. Often times, we'll also want to show the user a success message so they know everything worked. Symfony has a special way to handle this: flash messages.

To set a flash message, before redirecting, call $this->addFlash() and pass, in this situation, success. For the second argument, put the message that you want to show to the user, like Vote counted!.

62 lines | src/Controller/MixController.php
// ... lines 1 - 12
class MixController extends AbstractController
{
// ... lines 15 - 44
public function vote(VinylMix $mix, Request $request, EntityManagerInterface $entityManager): Response
{
// ... lines 47 - 53
$entityManager->flush();
$this->addFlash('success', 'Vote counted!');
// ... lines 56 - 59
}
}

The success key could be anything... it's kind of like a "category" for the flash message... and you'll see how we use that in a minute.

Flash messages have a fancy name, but they're a simple idea; Symfony stores flash messages in the user's session. What makes them special is that Symfony will remove the message automatically as soon as we read it. They're like self-destructing messages. Pretty cool.

Reading Flash Messages

So... how do we read them? The way I like to do it is by opening up my base template - base.html.twig - and reading and rendering them here. Let's put it right after the navigation but before the {% block body %}. Say {% for message in %}. Then, we want to read out any success category flash messages we might have. To do this, we can leverage the one global Twig variable in Symfony: app. This has several methods on it, like environment, request, session, the current user, or one called app.flashes. Pass this the category (in our case,success). As I mentioned, this could be anything. If you put dinosaur as the key in a controller, then you'd read the dinosaur messages out here. Finish with {% endfor %}.

87 lines | templates/base.html.twig
// ... lines 1 - 19
<body>
<div class="mb-5">
// ... lines 22 - 57
{% for message in app.flashes('success') %}
// ... lines 59 - 61
{% endfor %}
</div>
// ... lines 64 - 84
</body>
// ... lines 86 - 87

Typically, you'll only have one success message in your flash at a time, but technically you can have multiple. That's why we're looping over them.

Inside of this, render a <div> with class="alert alert-success" so it looks like a happy message. Then, print out message.

87 lines | templates/base.html.twig
// ... lines 1 - 57
{% for message in app.flashes('success') %}
<div class="alert alert-success">
{{ message }}
</div>
{% endfor %}
// ... lines 63 - 87

So if this works correctly, it will read all of our success flash messages and render them. And once they've been read, Symfony will remove them so that they won't render again on the next page load. By putting this in the base template, we can now set flash messages from anywhere in our app and they'll be rendered on the page. Pretty cool.

Watch. Head back to our page, upvote and... beautiful! We'll probably want to remove this extra margin in a real project, but we'll leave it for now.

Making our Entity Class Smarter

All right, look back at MixController. The logic for doing our "up" and "down" voting is pretty simple... but I think it can be better. Try this! Open up VinylMix... and scroll down to setVotes(). Right after this, just to keep things organized, create a new public function called upVote() and return void. Inside, say $this->votes++. Copy that, and create a second method which we'll call - you guessed it - downVote()... with $this->votes--.

143 lines | src/Entity/VinylMix.php
// ... lines 1 - 9
class VinylMix
{
// ... lines 12 - 116
public function upVote(): void
{
$this->votes++;
}
public function downVote(): void
{
$this->votes--;
}
// ... lines 126 - 141
}

Thanks to these methods, in MixController, instead of having $mix->setVotes() set to $mix->getVotes() + 1, we can just say $mix->upVote()... and $mix->downVote().

62 lines | src/Controller/MixController.php
// ... lines 1 - 12
class MixController extends AbstractController
{
// ... lines 15 - 44
public function vote(VinylMix $mix, Request $request, EntityManagerInterface $entityManager): Response
{
// ... line 47
if ($direction === 'up') {
$mix->upVote();
} else {
$mix->downVote();
// ... lines 52 - 59
}
}

Now that's nice. Our controller reads much more clearly, and we've encapsulated the upVote() and downVote() logic into our entity. If we head over and refresh, it still works.

Smart vs Anemic Models

This highlights an interesting topic. We've now added four custom methods to our entity: two that help read the data in a special way, and two that help set data. When we run make:entity, it creates getter and setter methods for every single property. That's nice, because it makes our entity infinitely flexible. Anyone from anywhere can read or set any property. But sometimes, you might not want or need that. For example, do we really want a setVotes() method? Is there really a use case in our code for something to set the vote count to any number it wants? Probably not. We'll likely only need upVote() and downVote(). I will keep the setVotes() method... though, because we use it when we generate our dummy VinylMix object.

But, in general, by removing unnecessary getter and setter methods in your entity and replacing them with more descriptive methods like upVote(), downVote(), getVoteString(), or getImageUrl() - methods that fit your business logic - you can, little by little, give your entities more clarity. Our upVote() and downVote() methods are super clear and descriptive. Someone calling these doesn't even need to know or care how they work internally.

Entities that only have getter and setter methods are sometimes called "anemic models". Entities that remove these and replace them with specific methods for your business logic are sometimes called "rich models". Some people take this to an extreme and have almost no getter or setter methods. Here at SymfonyCasts, we tend to be pragmatic. We usually do have getter and setter methods, but we always look for ways to be more descriptive, like by adding upVote() and downVote().

Next, let's install an awesome library called DoctrineExtensions. This is a magic library full of superpowers, like automatic timestampable, and slug creation behaviors.