I recently found on Coil’s blog, here: http://www.strangebuzz.com/post/2012/01/28/Load-fixtures-with-Symfony2 how he went about creating fixtures from Yaml files in Symfony2. This is something that I’ve been willing to have for a while. But I needed more than just loading the data from Yaml. My need for easy to use fixtures comes from testing and setting up the database for test purposes. Fixtures can have many different needs. You might need some of them in production because they bootstrap your database (for example set the client_contract possible status to prospect, proposal, signed_contract in a contract_status table), some of them are required for development.

I’m sure absolutely everybody has this problem! Well … maybe not but some of us do! So standard good practice these days is to have your object accessible through a url friendly so-called “slug”. This means that this exact post here on this blog will be accessible at http://sf.khepin.com/some/date/doctrine-sluggable-and-transliteration instead of being at http://sf.khepin.com/some/date/67. There’s a few good reasons for that: here 67 would be the primary id of my post.

If you’ve ever used FOS user bundle, they handle all the translation for you for the form’s field labels. Whenever a translation is not there, you see the field’s id instead of seeing any label based on the field’s name like this is usually the case. This seemed pretty cool to me and I couldn’t help but keep thinking “I want that too”. The reason is that my translations are based on “keys” instead of the actual text.

The other day I explained the problem I had: when you build a SaaS service, each customer’s data must be seen by him and him only. It would be a disaster if one of your customers could see it’s competitors data so this has to be taken seriously. I call these “realms” though I have no idea if this is a standard term for this or not, but to me it represents the fact that you lock each piece of data into separate parts that can not be accessed from one another.

First of all and before getting started, today has been declared to be #bloggerlove day by @caefer over there so be sure to leave comments on the blogs you like and read. As he says, bloggers make our lives easier and share a lot of expertise in many different domains. It’s always great when you’ve spent hours researching on something and put some more time to try and explain it to receive a simple ‘thanks’.

As I am currently starting my company (http://linads.com), some parts of the app I am building need to be highly dynamic. At the core of the app is a planning management that is pretty complex because it needs: To be active (users should be able to not only view the planning, but also create new bookings from there) To start from a yearly view (by month) but go into details at the daily level (showing all day of the years on one view is ugly and not usable, showing days within just one month is not enough as bookings might be longer than that) To show all current bids from customers on each possible item at any given time.

Simple one for today! For business apps, people are not really confident with the idea of using a “remember me” option on login. Because the security of your financial data prevails over the pain of logging in every time you want to use the app. As I installed FOSUserBundle, the login form always shows a remember me checkbox. I wanted to not only get rid of that in the template, but also make sure that the possibility to do so was actually disabled server side.

I had a little issue with Symfony2, every time a new version is released, there is a super convenient way to update your current version: Download the vendor-less version Extract the deps and deps.lock files to your project root directory Run ./bin/vendor update All is fine until you start to have a few of personal bundles managed through the deps file. Then you have to carefully merge your own files with the new Symfony2 ones.

It’s been quite a road to understand the symfony2 CollectionType, and to make it work the way I wanted! This article will be brief (I’ll try at least) and will not explain a lot because this reflexion started 3 articles ago so all the information on why things are made like this, why is my code like that etc… can be understood through those articles: Form composition in symfony2 First shot at the collection field Something is broken?

Updated Post: Things can work! It’s not as intuitive as I first thought, but I was on the right track and almost had the solution. The complete code for this bundle is now on github: https://github.com/khepin/ProductBundle if you want to review it. I’m still trying to get to understand more about symfony2′s form framework. And especially the CollectionType, which should be a powerful and interesting part of the framework.