FTG: A Code Generator for Drupal 7 Field Types.

Life before Code Generators

I love automation.

It’s something that lives deep inside me, and I always seem to seek it as hard as I can, even when dealing with the most trivial things. Yes, even those things for which automation might not even give huge benefits at all. That is, perhaps, because I just fit in the prototype of lazy developer who wants to reduce the work to do as much as possible, or simply because I like the challenge of grabbing a problem that requires some hours and several steps to get solved, and turn it into a trivial matter that can be done in less time, by anyone.

And that’s what I did a year and some months ago, when I wrote the Field Type Generator module for Drupal 7, which I’m releasing today. Depending on your background, and the processes and tools that you use for Drupal development, this might or might not be as great a tool as it is for me, but I can tell you that in my case, it’s a little gem that has saved me a lot of time over the last year.

There are some reasons why I decided to write the module:

1. As mentioned, I love automation.
2. This book, by Chad Fowler, convinced me that my love for automation was good, and that I should automate things. And that includes writing code generators.
3. I was finding myself writing plenty of custom field types to be used in Drupal nodes and entities. All from scratch. Best scenario involved copying and pasting code to amend plenty of things afterwards.
4. There wasn’t a clear, standard approach to the task in the company I was working for. Most devs were fairly new to the concept of custom field types, in fact, and would spend a fair amount of time writing them from scratch, too.

So what is it, then?

The Field Type Generator is a code generator to create custom field types based on Drupal’s Field API. It allows developers to create a custom field type, containing as many columns as they want, and download it as a fully-working module that they can drop in a drupal repository, ready to be installed and used in any Drupal site.

The module makes as little assumptions as possible about the purpose of the created custom field type, and it’s expected that developers will still have to add some custom code to the module created for their specific needs. So the goal is not to solve anyone’s problem in 5 minutes, but instead, solve about 3/4 of the task in 5 minutes, letting developers focus on their particular requirements (e.g: custom validation of data).

If he approves, you can’t just ignore it.

Why now?

Sure, I could have released it before, but I didn’t. Why? Because I wanted my company to benefit from it a bit more before releasing it for everyone out there. I could mention a few more reasons, but there’s no point on denying that the main reason was probably that.

So why now? Well, I know a few developers out there that make heavy use of custom field types, and I’m fairly confident that this utility is going to be very useful for many people, in the same way it’s been for me and some of my colleagues.

Just go and try it

I don’t wanna keep you for long here. The good stuff is in the module. Really. Just download and enable, create a custom field type, and see what you get with it. If you like it, please comment. If you don’t like it, comment too, but be nice! I’m leaving a 4-minute video here showing what the module can do for you. Also, you can get the module generated in the video from here.

Did you like it? Don’t forget to share it with any dev who might be interested! If you find any issues with it, I’ll be happy to apply patches, but keep in mind this was done as a proof of concept, and even though it works well, it’s not meant to be a perfect tool to cover all possible cases out there!

Final note for developers

There’s a small caveat a colleague mentioned to me recently, that you might need to amend after generating a custom field type, depending on your use case. It’s pretty simple, and I’ll get it sorted in code soon. This issue does not affect the generated module at all, and it’ll work as expected. If you’re not saving the entity that uses your custom field programmatically, this doesn’t affect you. 

If you are, you’ll need to edit the “_field_presave()” hook implementation generated. The reason is that there’s a wrapper array that contains all the columns data for your field, added for better UX in entity forms. When saving an entity from code (not from the entity form), the wrapper won’t be present, as it’s added by the widget form, and Drupal will throw an error. All you need to do is add a check so that the wrapper is only used when the entity is being saved after a form submission (ie by checking the url path, for example). That way, when the entity is saved from any other place, the values of the field will be read just as they were loaded from the database.

Update: The caveat of _field_presave() mentioned above is fixed in 7.x-1.2 branch.