Wrapped present image

As mentioned earlier, the concept of wrapping content into relational data structures while an extremely powerful and controllable result, requires explicit knowledge and planning of that result. I have found that this step is all but ignored for the most part when assembling websites. To ask a Site Builder to now become a Data Architect at the same time sounds like a pretty big request, but in reality, it should be automatic. Perhaps these two disciplines have always been separated due to the lack instruction on how to accomplish both at the same time. I discovered that both of these tasks can easily be performed at the same time with the use of a simple spreadsheet. 

Assume you are packing a box of items for shipment. A major component of that package is the resulting packing list. But to have a packing list we must assemble the "ship-able" items into a container and verify its contents. The last step after verification of the shipment is to label it appropriately. This concept has nothing to do with Drupal, but you'll soon see where the similarities are profoundly related.

Assembling the kit (items in the shipping container)

Our Drupal website really is a kit. It has many working parts. We must define what those working parts are in order to provide a website solution. Every website has a purpose. One approach to creating information architecture is to clearly define the "master" purpose of the website which will allow you to identify relational entity structures that "compliment" the master purpose. Our 'master purpose" becomes our master content type.

Assume we are tasked to create an event website. This website is to display an event, its venue, people attending, featured people, schedules and what a visitor can expect to see while at the event. Our master purpose is the Event. The venue, people, schedules and attractions "compliment" the event.

The Master content type (the shipping container)

To create an Event content type in Drupal is a simple task. But there's a nuance to that task that is overlooked very often. That nuance is the machine name. But why is the machine name of a content type such an important step?

  • It gives the content type an explicit name of your choosing and allows database indexing to act on that machine name while being queried.
  • All fields contained within that content type will share the same machine name before the field name. This allows the Views module to clearly gather field data in a very defined manner using the indexed machine name.
  • Fields that are entity references out to other content types also begin with the same machine name followed by their own machine name. This allows simple and visual identification for origination and destination of data relationship.
Content Type ct_machine_name field_name field_type field_machine_name
Event even Title    
    Date popup calendar even_date
    Type entity reference to eventty even_eventy_ref
    Venue entity reference to venu even_venu_ref
         
Event Type eventy Title    
         
Venue venu Title    
    Address text venu_addr
    City text venu_city
    State text venu_st
    Zip text venu_zip

 

In this table we have encapsulated The Event and Event Type relationship. The Event Type node will only have a title field as shown. The Event Type node effectively removes the need for taxonomy due to its intended behavior of "descrbing the type of event". As an example of an Event Type node, we could simply use: DrupalCamp, or, Workshop, or, User Group Meeting etc. In this same table, we have also accounted for the relationship from Event to its Venue using the same, simple entity reference logic. We can then control how many related records we can create based on the referenced entities cardinality (how many values we allow). In this case, we only want to allow a single value on the Event Type and Venue. While a very small structure, this same set of steps can be duplicated across other content types as well and offer the same simplicity as well as controlled power. Your understanding of the above table completes our Shipping Container with related items. The spreadsheet itself serves as the packing list. All that's left now is to go into Drupal and implement our IA with content types and fields. If in doubt, simply refer back to your IA. The implementation of these methods described now effectively has bridged the gap between a Site Builder and Data Architect.

Before proceeding any further, using the above table and its logic, test yourself on its content while using simple relational database terms:

  • One Event has One Event Type (a 1 to 1 relationship)
  • One Event has One Venue (a 1 to 1 relationship)

So why is this concept so powerful? The Event node "owns" the related nodes created. This means that these related records are in fact, effectively linked to their Master Node. But, as we mentioned before, all Drupal nodes are technically orphans. So, while these related nodes are linked to their Master node, they are also technically orphans which can be related to other nodes or master node realtionships. Our UI will be the tool that displays these related records as linked to their mater node. This will soon come into focus and be clear.

Unwrapping the package

Everyone loves to open packages. But I think we can all agree that a package wrapped with care and elegance is much more attractive than one with no care or elegance. With our new powerful data architecture methods comes the task of giving end users an elegant and intuitive user experience above and beyond what Drupal provides us "out of the box".