Blog posts by Iltar van der Berg

Rethinking Form Development

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.

What are Bundles in Symfony?

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?

Symfony Security, Roles vs. Voters

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!

The Basics of Symfony Security

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!

Decoupling Your Security User

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.

Avoiding Entities in Forms

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.

Iltar has been working with Symfony since 2009 and still using it today. He is usually available in #symfony on freenode where he is also part-time channel operator.

Copyright © 2016