Our Drupal team review the action from day three at DrupalCon Amsterdam 2014...
An Overview of the Drupal 8 Plugin System
Joe Shindelar gave a thorough and comprehensive introduction to the Drupal 8 Plugin System. He used the relatable real-world example of an ice cream shop to demonstrate what the system is used for and then went through how you would go about making your own plugin with code examples and diagrams.
This is definitely a must-see talk for anyone wanting to learn about the new Plugins System and I would heartily recommend looking at this blog post covering much of what was in the talk or watching it on YouTube.
Field API is dead. Long live Entity Field API!
The talks mainly went over how this API has changed for the better, why it was changed in some instances and how to use it. I won’t go through the whole session piece by piece as I’d just be repeating what can already be seen in the recorded talk.
This sessions was received very positively with lots of rounds of applause throughout - it seems everyone is very happy with the direction this API has taken, myself included.
The opening session today was a series of 5 minutes talks intended to raise awareness of an specific topic (risk, the #D8in8 initiative), highlight a new module (cointools; Druphet) or just ask the audience a question (what is the correct response to risk?; how do we get distributions to roll in security patches faster?).
The stand out topic for me was the Drupal 8 Console project which integrates Symphony’s console into Drupal. This gives you a command line interface for creating a completely new Drupal 8 custom module, complete with router paths and info files from just a few commands. The interface can even create content, such as a form with inputs and submit functions that can be live in moments. It definitely looks like a project to investigate further: if it works as well as it seemed to in the presentation, it could turn any PHP developer into a Drupal Dev in a matter of hours.
Because it's about the interactions. (Better UX through prototyping)
Websites are dynamic, living creates, so why do we always try to show a client what they will be like by giving them a series of static pieces of paper? Working code fast is a basic tenet of the Agile approach, and good prototyping can give you a basic approximation of a site for a client to test and refine on any number of different devices.
This session went over a number of different options for prototyping in a Double Diamond kind of a way, reminding us to focus on functionality not design, and get the page built as quickly and dirtily as you can so that you aren’t too invested to scrap it and start again if you need to. The approach they favoured was creating a prototype using HTML, a bit of PHP (mainly to bring in a Drupal template) and some JS. I’m not 100% sold on that idea - if you need a quick and easy way to throw a prototype site together, there’s this thing called Drupal that is pretty easy to get up and running - but the ideas behind the approach are very convincing: under the right headwind, prototyping lets you create a codebase, wireframes and a client specification before the design process starts. It front ends the work, but should make the rest of the process relatively stress free.
Building Modern Web Applications with Ember.js and Headless Drupal
This one was much more of an introduction to Ember.js than it was about how to integrate it effectively with Drupal, but given that drupal is still at an early stage of this kind of stuff that’s not all that surprising. What it did make very clear, though, was that this is the way that websites are going to be built in the future: users expect fast interactions and they want their content to load now. Single page websites - which is what Ember.js builds, with page content changing through isolated AJAX calls - are the future of the web.
A Decoupled Drupal with Silex
This was a really engaging talk by @crell about a 2013 project to serve video metadata to anything upward of tens of thousand of users on any kind of device. The end output wasn’t content, but an API that could be triggered from any kind of device, any where. So a combination of services were tied together to take advantage of what each did best: the data was provided in XML by the client, processed in Drupal, pushing into an Elastic Search database where is was then consumed by Silex which pushed it out as an API.
This project laid a lot of the foundations for what became Drupal 8’s REST API, and showed a glimpse of the future for Drupal: using a combination of different tools and services to build the best service you can is going to be the default once Drupal 8 gets more established.
That's all from us at DrupalCon Amsterdam- we've had a great time and hope you have too!