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. And some of them for testing of course and for testing you might even want different possible cases.
Based on this idea I created a new bundle for this purpose: https://github.com/khepin/KhepinYamlFixturesBundle
The bundle allows you to define fixture files in the YAML format of course. You have a command line tool to load all your fixtures in database. As well as a service living in the DIC so that you can load fixtures in your test setup function.
The bundle provides a notion of “contexts” which might be the ‘production’, ‘test’, ‘dev’ cases we just talked about for example. This allows you to either load only the standards fixtures or load the standard ones plus the ones specific of a given context.
Well that’s it for now, but I hope it helps many of you I’ve seen looking for this on the interwebs. Any feedback is welcome to help make it more usable for not just me.
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. For a post on a blog it’s not very risky to expose your internal logic that your ids are simply increments, but it can be a problem some times. It means people can guess what url things will appear at in the future for example. So if there’s an ipad to win by being the first one to put a comment on your next blog post. Since I already know its url because it’s gonna be last post’s ID + 1, I can create a bot to start posting as soon as this URL is available. Or if you have private user data and some of it is not so secure, having all of your user’s profile urls known as well as all their status updates or whatever is also pretty bad.
If you’re using MongoDB and use those primary ids, then all your urls become ugly instantly with really long ids.
And URL search friendliness can only help your SEO.
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. So if my label reads “Contact person’s email”, I’d have to have a key with this name. But when I change this label in English to “Contact’s email” then I would have to change all the keys in the translation files. Which … I don’t want to!
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.
So all my data, all the entity classes and all the database tables have a special field that makes an association from this entity to the realm (a client company of the product in this case).
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’. Or if you don’t want to comment here, you can always send a postcard to @fabpot! Ok, now on to today’s problem!
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.
If you want something like this to be simple to use and browse through, you can’t show everything at once but need to let the user view more details where he needs to without ever leaving the page.
In this post I’ll try to explain how I use Symfony and a handful of JS libraries together to make this work.
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.
Since I don’t really enjoy this tedious work, I created a small “UpdateBundle” that does the trick for you.
It adds a command: “deps:update” that will merge the current deps and deps.lock with the new ones contained in a zip file at the root of your project. So you can download the Symfony2 vendorless distribution as a zip file, put it at the root of your project, run the command and be sure that:
- All the bundles you took the time to manually add are still there
- You have the latest version of symfony
Right now the bundle comes as is, has no tests whatsoever and has only be tried by myself. You can find it here: https://github.com/khepin/KhepinUpdateBundle
I’ll add tests to the bundle later. (Mainly when I understand how tests work for the command line. Not very successful so far!)
Maybe I’ll start maintaining a zip file containing just the deps and deps.lock for symfony’s latest version available online and improve this bundle so that it can directly fetch the online versions, thus saving one step.
For now, you can use it “as is if you want to”.
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?
Part of the solutions are in the comments too. Continue reading
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.
I’ve “almost” done it now, but when it comes to saving content to the database, I still have some issues. Trying to find where those come from, I found some things that I find inconsistent in the forms for symfony2 so far. I’ll first explain quickly how I’m now able to use the CollectionType, and then explain where I find it not consistent and why it’s blocking me now.