Why 3.0 Part 2? – Field Type Registration

Last post, we walked through the new UI and how we are attempting to create the first truly intuitive form builder for WordPress. If you missed that post I’d recommend reading it before continuing. It’s ok. I’ll wait.

Welcome back!

Now that we have some of the UI discussion out of the way, I’d like to dig into some of the more technical aspects of the new version. Specifically, how fields are registered. Just as a warning, this post will probably be less interesting to non-devs and include fewer images than the previous one. 🙂

One of the biggest drawbacks to our current codebase is how we have implemented field type registration. Following the WordPress post type registration model, our registration system uses a multi-dimensional array along with helper functions to define field types. You can see how it currently works here. While this works great for posts and custom post types, it doesn’t work so well for field types. If you’ve ever wondered why you have a “Validate as Email Address” checkbox on a First Name or Textbox field, this is why. This registration system doesn’t allow us to extend field types or create non-generic field types. First Name is showing the “Validate as Email Address” setting because it’s really just a Textbox field with a fancy name.

By way of an example, let’s say that you wanted to create a Date field type: a textbox that shows a datepicker. This isn’t uncommon, and currently to do this you have to add a textbox and select the “Datepicker” option. This isn’t the most intuitive method for users looking to add a Date field to their form. Even though it’s not really much different than a Textbox, to create it you’d have to copy/paste all of the code in the Textbox field type definition and change all the stuff specific to your new Date type. You’d be copying 354 lines of code just to add a datepicker. This is the opposite of DRY; it’s overtly RY.

Instead of repeating code in fields that are similar, what if we could just extend the Textbox field type and modify the settings so that it matched our Date field? That would be much simpler, and would make your Date field only a few lines. It would also mean that we could remove unnecessary settings like “Validate as Email Address” on a Phone field. Of course you don’t want to validate as an email address! It’s a Phone field!

This is exactly what we’re doing in version 3.0. Our current field type registration system will be replaced with one that is class-based. We’ll have more specifics on this system as we get closer to a beta, but we’re very excited at the prospect of simplifying our field types and expanding them at the same time.