Part 2 of 4 – On October 4/5, 2013 (depending on your time zone), I hosted a live Hangout on Air with three major Drupal core contributors: Lee Rowlands (larowlan), Tim Plunket (tim.plunkett / @timplunkett), and Daniel Wehner (dawehner / @da_wehner). We talked about what's going on in Drupal 8 and how you will benefit from all the new stuff. This post is the second of four that cover the details of that conversation.
In part 1, you can meet Lee Rowlands, Daniel Wehner, and Tim Plunkett and hear about the events that led to this conversation.
Backstory – Lee Rowlands felt "We do a lot of introspection and critical analysis in open source and Drupal, that's what makes it great. But sometimes I think we don't stop and celebrate the wins," and that some of the noise going on around the Drupal 8 developer experience didn't touch on all the wins that we're getting from the changes in Drupal 8. He wrote a blog post and gave a presentation at the Melbourne users group outlining some of the many ways Drupal 8 will be a great experience for developers.
"I work all day on Drupal 7 sites. Drupal 8 is where I get to do the fun stuff. There are a lot of things in Drupal 8 that I couldn't wait for, dealing with shortcomings in Drupal 7 on a daily basis. 'I want it now' kind of stuff (I picture Lee having a tantrum at this point), in particular the plugin stuff, and the entity filed API changes. That was my motivation for that talk."
The conversation video
D8 win: Entity field improvements
Lee describes how things are in Drupal 7: "In Drupal 7, there are massive arrays attached to nodes that represent the field data. For every field there's a property, which is the name of the field, then there's an array which has a language and then it's an array of values and each one of those is keyed by columns in the field table ... It's very arbitrary, it almost seems so. The only way to debug it, or to figure out what is going on is to either put a break point where you get to that code or to dump out the contents of the node and see what you're doing.
But in Drupal 8, "The improvements in Drupal 8 that the entity/field team have worked on – and that I have been exposed to first hand by the Forum and Comment [module] upgrades – it's a far greater developer experience." Check out Lee's presentation (slides 7 through 11 here) for code samples showing just how much easier this is to work with in Drupal 8.
Tim compares getting a TID in Drupal 7 v in Drupal 8: "Just this morning, I was working with a taxonomy term and I wanted to get a link to it ... and it was Drupal 7! I had to remember, I have to actually do '/taxonomy/term/./tid' instead of [in Drupal 8] just calling a method on it and getting the URI," and in Drupal 7, "every entity has a different way of saving things. The massive unification [in Drupal 8] is amazing."
About this win in simplicity and uniformity, Tim comments, "The sheer number of entity types we have ... If you learn parts of the entity system, that expands to 40 things and instead of having to learn 40 things, you learn one thing. There's no way this is 40 times harder." So there's a learning curve, some getting used to thinking about the new coding paradigms (PHP 5.3, OOP, etc.), but everything works the same way, you can reuse what you learn across every system. You end up learning something (perhaps complex), but you learn that one thing and it works everywhere!
Lee continues, "If you're not touching the low-level stuff, you probably won't even need to worry about it. You just need to use the parts of the API that are user-facing like the :getPropertyDefinitions() method that you can call on any field or any entity and it'll tell you the properties that it has. It's self-documenting."
Daniel also points out that this unification could lead to new and exciting developments in the contributed module repository, too. "The Drupal 7 Entity API Module is the basis of a lot of great solutions [Search API, Drupal Commerce stuff, etc.]. Now all these tools can automatically use just the core API."
D8 win: Plugins
Lee takes the block system as an example of how the Drupal 8 system helps developers: "My first exposure to this was through the Custom Block Module, which lets us have fieldable, translatable, revisionable blocks in core. It uses plugins to expose the block type. I think the block is a good example of where the plugins is far easier in Drupal 8."
In Drupal 7, to define a block, you would have up to four hooks. You'd have a hook to define the info (the metadata about the blocks). You would have a hook to define the view. If you had a settings form for the block, you'd have another hook to do the settings form and another hook to save the settings. If you had more than one block, defined by your module, then each of those (except for the info) would have a switch statement and that would switch on the delta. The size of the functions would soon start to swell. If you had four, you'd have a massive switch statement ... As a developer, that gets really unwieldy to work with.
In Drupal 8, "Keeping them all together is what the plugin system gives us.
- You have one file for each block.
- If you want a new block, you can copy and paste the file and update the metadata and the implementation and you've got a new block.
- Instead of working in four separate functions in four separate places, in one or two files, you just have one file for each block.
- All of the logic is there where you need it.
- The metadata is defined in the same place.
- You don't have to go into any info files and declare the path to your class, 'cause it's auto-loaded.
- It's well contained and encapsulated in a single file."
Tim goes on, "I think the number one chunks of custom code I write on a daily basis are field formatters," and the same thing is true for them, "but even more so. One of the first modules I wrote from scratch was the Field Collection Table formatter module, which just provided another field formatter for field collections. But because it's all procedural code [in Drupal 7], I had to call the same functions that Field Collection was trying to use, and then take their return and manipulate the data structure directly after it was done doing all of its five steps."
"In Drupal 8, I would just sub-class their formatter, extend it, and override just the parts I need. There you have that whole reusability. ... [In Drupal 7], there are 7 hooks, five of them are required, two are optional and I had no idea which ones were which. Stuff just doesn't work if you get them wrong. And now [in Drupal 8], you have a single interface that says 'these are the methods you need, and these are the ones that are optional, and here's how you do them.' If you want a new one, you copy and paste the entire file and you're done. That's it."
Daniel hits it right on the money: "It's great to see that we now have 20 or so plugin types in [Drupal 8] core. Everything you do, like fields, everything in Views, everything with images and image effects – everything is the same, [everything is a plugin]. You just have to learn one single idea and you can apply it anywhere. It's so much better than before ... In Drupal 7, there were also 20 possibilities and everything was custom. Now, it's this big unification. "
Tying up all the loose ends, Lee explains how the entity/field improvements and the plugin system work in harmony to provide a great developer experience: "The field formatters give you the best of both things we've talked about:
- You've got the plugin and you've got the object inheritance in the single file,
- but the data structure of the formatter (instead of it being a large, arbitrary array), you're handed first-class field item objects, which are the items that make up the field.
- Each of those has all those methods for data definition and fetching the values.
- If you're using an IDE, you'll get auto-completion on those."
"Field formatters is a classic example of the experience in Drupal 8 being far superior."
The topics we covered
- Meet Lee, Tim, and Daniel, and how the conversation came about (part 1)
- The Drupal 8 entity system (part 2)
- The Drupal 8 plugin system (part 2)
- Why some people are worried about Drupal 8 and how we see things. (part 3)
- How Drupal core developers coordinate and cooperate. (part 3)
- Will Drupal 8 be more code-heavy? (part 3)
- Theming in Drupal 8 (part 3)
- Where's the Drupal 8 module upgrade info? (part 4 - Answer: it's a little early as of October 2013)
- What's the most compelling feature in Drupal 8? (part 4)