To actually use Symfony2 forms, all you need to do is read some documentation, a few blog posts and you’ll be up and running in a couple of minutes. Understanding Symfony2 forms however, is a whole different ballgame. In order to understand a seemingly simple process of “adding fields to a form”, we must understand a lot of the basic foundation of the Symfony2 Form component. In these blog posts, I’ll try and give some more insights on this foundation.
A really neat trick in the Symfony Security component is the fact that you can impersonate or “switch” users. This allows you to login as another user, without supplying their password. Suppose a client of your application has a problem at a certain page which you want to investigate. Sometimes this is not possible under your own account, as you don’t have the same data as the user, so the issue might not even occur in your account. Instead of asking the password from the user itself, which is cumbersome, and not a very safe thing to begin with, you can use the switch-user feature.
Once in a while I like diving into code and see how things work under the hood. And as the symfony2 framework consists of many different components, bundles and bridges, there is a lot to discover. But ultimately, the code itself mostly isn’t really as complex as it might seem from the outside world: just like a good magic trick, once unraveled, it all seems very simple and makes sense.
However, this is not true for one of those components: the security component. This black box full of dark magic doesn’t like to give up its secrets, and after some (miserably) failed attempts, I am trying to unravel it once more in a few blog posts. Either we achieve complete victory, or fail yet again.. At this point, I will give both fair odds.
Note that this blogpost are in the first place written for me personally. There may (and probably will) other blogposts be out there detailing the component, but I’d rather discover and share the experiences myself. Assumptions I make, may or may not be valid and might not even make sense, but then again, these posts should be considered as a learning process, not a hard truth (which I will never pretend I will have on anything).
One of the “golden rules” of symfony2 is to never hardcode urls or paths inside your code or templates. And letting symfony deal with the generation of your urls and paths makes your life a lot easier as a developer. But one of the things I see regularly is that people are still hardcoding their logout urls like using “/logout”. But logging out is actually a bit more complex than it might seem, and using a simple /logout might work for most cases, but there are better ways to deal with this.
A web application is not complete without an API nowadays. APIs allow third parties - or just end users - to use the data from the platform for whatever they want. But by allowing applications to make automated calls to your API can result quickly in our systems overloading. Too many times third party applications will be polling your API when they don’t really need too, and maybe you can lighten the load a bit with some heavy-duty caching, but in essence you want that every API call made matters.
Sometimes (or actually, a lot of the time), handling forms will go beyond the basics. And even though Symfony2 gives you out-of-the-box a really clean way of creating forms, it sometimes just isn’t enough.
Fortunately, you are not alone in writing forms, and many posts exists with information on how to handle complex forms. In this post, I will try and demonstrate how to create a dynamic form where you can select a city based on the chosen province.
If you do command line work under Linux, you probably are aware that when pressing
<TAB> automatically completes your
command, or give you options for it that are currently available. For instance, when entering
cd l en pressing
bash gives you a list of all directories starting with an
l, which you can select instead of type. If there is only
one available directory that starts with an
l, it will automatically fill this in for you.
A great way to speed up your CLI development work, and an even better way to get acquainted with all options that are available to you for certain applications.
It happens more and more: large projects where your symfony2 site is just a small part in the big picture. Lots of additional components might even play a bigger part, especially when you are dealing with asynchronous components which are connected through message queues for instance. So the question is: we want to make sure that all your components are using the same settings, be it your symfony2 project, your bash-scripts, 3rd python application and whatnot. How do we keep this all in sync?
If you know Symfony2, you probably are using (or at least, have heard of) the @paramConverter annotation from the SensioFrameworkExtraBundle. This is a really simple way to convert slugs into entities. But lots of times I find myself having multiple slugs inside my routes, and this is something the @paramConverter annotation cannot do. So that’s why I’ve created the multiParamConverter.
Doctrine’s DataFixtures are a great way to add test data to your application. It’s fairly easy to get this going: Create a fixureLoader that extends Doctrine\Common\DataFixtures\AbstractFixture, had a load() method and off you go. However, sometimes you want your data also to be protected by Symfony 2’s ACL layer. Since there isn’t a common way to do this, here is one way on how I implemented this
As you may now by now, I’m a big fan of using Puppet for configuration management. Since the rise of virtualization,
these applications are becoming one of the more dominant tools in a developers tool chain. Together with other tools,
setting up a complete development environment with just a single command is not only reality, but it’s becoming for a
lot of developers a daily practice. But even for open source projects like