Blog posts by Iltar van der Berg
Written by 
Iltar van der Berg on December 17th 2016.
In one of my previous blog posts, Avoiding Entities in Forms, I've shown how to decouple your forms
from your entities. Afterwards I got feedback and most of it was about the lack of examples and the flow, when
to fill your data and how to get this back in the entity. However, often I notice that developers design forms
based on their entities. This can lead to complex forms because you're confined to a strict set of properties.
Developers often get struck with unmapped fields and form events to work their way around those limitations.
With Symfony Forms I highly recommend to follow the composition over inheritance
principle. Small form types are easier to re-use and make it less complex to build forms. Moreover, this allows small
data objects to have specific goals with validation for their specific case, rather than complex validation groups.
Written by Iltar van der Berg on December 5th 2016.
People often refer to bundles as modules or re-usable code for Symfony applications. When a developer has experience
with Symfony1 or another framework with the module concept, it might seem logical that this is what a bundle represents
in Symfony.
So what is a bundle? When do you need one and what can it do? What's the difference between an AppBundle and a vendor
Bundle?
Written by Iltar van der Berg on August 20th 2016.
In my previous blog post I've explained the basics of authentication, authorization and how this is dealt with in
Symfony. Due to the size of the post, I've left out several important topics such as roles and voters; Both an equally
important part of authentication and authorization. A common misconception is that roles should be used to check
permissions. In fact, they should definitely not be used to check permissions directly!
Written by Iltar van der Berg on August 8th 2016.
One of the more complex parts of Symfony is probably the Security and everything that comes with it. It's not only
rather big, it's also quite flexible with lots of different concepts which often confuse developers. Often enough when
developers implement a security system for their website, they call it Authentication or Authorization yet often don't
exactly know what they are exactly supposed to call it.
One quote I always refer to is "if you can't explain it simply you don't understand it well enough" and I think it's
rather fitting for most cases. I think I've reached a point where I can explain it well enough, so bare with me!
Written by Iltar van der Berg on July 3rd 2016.
A lot of developers come to #symfony and ask how to implement a login or authentication system. It's quite common to
have a bunch of features which require authentication and authorization. While authentication is identifying your user,
authorization is granting permissions to this user.
One of the steps of implementing the security features of your application, involves creating an object to contain
your user information such as your username, email, password and user id. If you have followed the Symfony docs,
you will most likely have ended up with a User entity implementing the
Symfony\Component\Security\Core\User\UserInterface. I would like to show you an alternative- decoupled- approach
which will prevent several issues within a Symfony application.
Written by Iltar van der Berg on May 20th 2016.
Being active on IRC, almost every day I see questions coming by regarding forms and entities inside. This does not only give you a headache but it's also risky. You wouldn't want to flush an entity in an invalid state!
"But Using Entities in my Forms is Easy!" Yes, it's certainly easy. You don't have to write any additional code to connect your validation rules and data mapping, not to mention that when it's valid, you only have to flush your entity and you're done. Using this method is especially easy when using CRUD and makes developing applications faster, thus RAD friendly.
