Recently, with the Broward Drupal Users Group I created a back end for modeling Drupal Camps. The main idea was to give DrupalCamp organizers a super fast way to get their site launched with minimal content initially. Then, as more information becomes available, the organizer can layer information over the top of the foundation. At minute one, all an organizer needs is the camp title and a date(s).
To create such a back end requires explicit directional data logic and allowing for layered additions. But if much of the information is already available, the system would need to create the layers behind the scenes. The secret lies within the node UI. So, to implement this I decided on the old fashioned "one to many" and "one to one" database concepts. More directly, the following:
- One camp can have many camp days
- One camp can have one location
- One camp can have many featured speakers
- One camp can have many time slots
- One camp can have many sponsors
- One camp can have many calls to action
- One camp can have many schedule items
Each of these relationships contain their own fields and entity references to other relationships. This then makes our system truly a hierarchy based model.
- One camp can have many schedule items.
- One schedule item has one session
- One session can have many instructors
- One schedule item has one time slot
- One camp day can have many time slots
I fully understand this concept can make your eyes cross when thinking through it, but the images below might serve to more easily illustrate the concept. The elegance of something this complex is in how a content editor interacts with all content. I can't think of an easier way to interact with all these different types of content except for a single UI.
Default camp UI
Time Slot relationship expanded
Schedule item list
Schedule Item in edit mode from Camp UI.
Auto Node Titles and Mandatory Values
As you look through the above images you'll see a bunch of mandatory values, pre-formatted titles and content lists in drop-downs. These are derived from using entity reference Views, Auto Entity Label module and core widgets. The idea is that as content is saved, the title becomes part of a related node's title. Here's an example:
- Camp Day node is saved.
- Time slot is created with a relationship to Camp Day.
- Time Slot is saved with an auto label string with camp day - time slot type - time slot start time - time slot end time.
Here's an example of tokens with Relativity name spacing to build the above string from the Time Slot content type:
[node:field_tslo_cday_ref]: [node:field_tslo_tsty_ref]: [node:field_tslo_start_end_time:from] - [node:field_tslo_start_end_time:to]
The Nuts and Bolts of this UI
A very important concept to take away as you visit following pages is to note that there is zero custom code. It's Drupal core and the following modules to make something like this happen:
- Inline Entity Form
- Auto Entity Label
- Field Group
This is just one example of how I decided how to model the data, relationships, fields etc. There are additional layers of logic in how and when some of these nodes available in the drop-downs become visible such as workflow and moderation. All it is in the end is Drupal site building with an extra layer of logic for the folks tasked with content management.
But this teaching website is a single implementation of Relativity for a specific use case. Depending on business requirements and functional specifications, the above model probably wouldn't work for another type of site.