FTG: A Code Generator for Drupal 7 Field Types.

warcraft peasants building a town hall

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).

Computer guy, thumbs up gif

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.

3 thoughts on “FTG: A Code Generator for Drupal 7 Field Types.

  1. Bernard

    Good job on the module, it looks really good!

    Could you expand on the need to use a custom field type vs. using non-coding options like custom node types, field collections or custom entities via Entity Construction Kit?

    By the way, may I ask you what is the IDE shown in the youtube video?

    Great work anyway, keep it up!

    Reply
  2. Salva Molina Post author

    Hi Bernard, thanks for your comment!

    The IDE is PhpStorm (https://www.jetbrains.com/phpstorm/).

    The reasons for using a custom field type VS just another content type are mainly related to the nature of the data you’re storing, and the use that it’ll have within the system. I’ll give some examples, hopefully they’re useful to you:

    1.- You need to store information that affects only a particular entity in your system. This info is composed of several pieces of data, and it’s not meaningful to the site as an isolated piece of content, in any way. As such, it doesn’t have to be accessed in a separate page, it doesn’t need an individual entity / node, it doesn’t need particular access control settings other than those applied to the field itself, path settings, etc. In such cases, Content Types are redundant, and will add clutter to the User Interface (unless you take additional steps to avoid it), because they’re meant to cover other cases.

    2.- Despite point one, you could certainly use Field collections or a custom entity. But then the data model can be still more complex than needed for the use case (e.g: always having to load a referenced entity, with all its fields, VS just loading the instancies of a single field for the parent entity). Additionally, you’d still have to configure a view mode, tackle the export of the field collection and the different fields to Features, etc.

    3.- Imagine your field type offers settings likely to change depending on what content type / entity the field type is used. If you use a content type / entity / or FC to group several fields, that won’t do the trick, because the configuration for the group of fields will be always the same, whereas with a custom field type, the configuration can be changed in every place where the field type is used.

    In short, it’s mainly about picking the data model that fits best the use case. Custom field types are not meant to replace any of the other alternatives you mentioned, of course, but there are cases where they certainly have their benefits over other approaches, or, at the very least, make the minimum impact in the database.

    Hope that sheds some light on why / when to use them =).

    Reply
    1. Bernard

      Thank you very much for your comment, you made a few good points, I haven’t found much information on the topic.

      Drupal offers so many different ways of achieving the same purpose I sometimes find it difficult to make a decision on how to implement each functionality.

      Thanks again. I will give your module a try (and custom field types as well) and will give you some feedback!

      Reply

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">