We are currently working on a great project where Drupal is going to be primarily used for backend content management. The frontend will be developed in Knockout JS.
In order to exchange data between these two systems we are building an API in Drupal using the ‘Services’ module. We will exchange data via a ‘RESTful’ API.
Content model
Currently we are working on modelling the data: defining content types and fields.
In concept the content type ‘Story’ is displayed as follows:
(Beautiful handwriting eh;-) )
Well translated:
Set of data
As you can see we have to deal with item sets within a piece of content. So the content manager has to be able to make an infinite number of ‘story sets’ within the story. This is used to manage a page for the website visitor that is roughly looking like this:
Drupal modules Field collection & Multifield
Here we are dealing a lot with content sets. An obvious choice to manage this in the Drupal cms is the module ‘Field collection’. This allows you to define field sets within one content type and to manage in a user-friendly manner the content herein. When you own a relatively simple Drupal system, then the ‘Field collection’ module is an excellent choice, there is a good reason for the nearly 700,000 downloads and 100,000 Drupal installs. The module Multifield could also be interesting. It is only available in the Alpha1 version and can therefore not be implemented in a production environment.
Why compound fields
But in this project it is mainly about building a RESTful API. Therefore the ‘Field collection’ module is a bit cumbersome, as you’ll quickly discover once you start programming the API. In this case we prefer ‘compound fields’.
We are choosing Compound fields instead of Field collection:
- Data from one set clustered in one database table, instead of several databases
- Less overhead: no additional entity
- Drupal system is more flexible: more scalable, better performance
Configuring vs programming
Field collections are relatively easy to configure, compounding fields have to be defined through code. Initially this will cost you more time, but later you will catch this up very quickly. Your data is more consistently stored in the database and you control the data flow yourself.
Technical notes
I will discuss the technical implementation in a next blog. If you cannot wait, then go to the Field example module from the Drupal core.
Wrap up
OK, that’s it for now. Let me know if you have any questions/feedback.
