Meticulous inventory yields consistent and predictable results
When I decided to commit to finding more efficient ways to working with and providing solutions for Drupal, I had a major task ahead of me. I had to identify what I thought "worked well" and what needed improvement. When you think about how big and elaborate the Drupal framework really is, that task could be quite daunting. But, I got lucky to be honest. A good portion of what I was trying to accomplish already worked quite well but was in pieces. That scaled down my task to only dwell on what I thought needed improvement, how to assemble those pieces into something brand new and how to implement all this on a live production site.
Along with the above, I had to provide the following additional features that I considered my mandatory Inventory Items:
- To allow developers of all skill levels to take advantage of this procedure by ensuring the steps were well within the skillset of even a beginning developer.
- To ensure that this solution required ZERO code and or custom modules to be successful.
- To ensure that end users were given interfaces that were intuitive and followed their specific thought processes.
- To eliminate the need for using the content list.
- To eliminate the need for the Admin Menu unless logged in as an administrator.
- To completely remove the need for Taxonomy and its inherant complexities.
- To vastly scale down the number of modules needed to launch a Drupal site.
- To vastly scale down the footprint size of Drupal and allow for smaller hosting needs.
Good things have wrappers
Christmas and birthday presents, your favorite candy, UPS deliveries all have wrappers. Things that are wrapped all reside in a container of some sort. That makes storage of the items in the container a snap! Best of all, those items are clearly labeled by their container (think of a warehouse rack with multiple shelves). So the concept really is, a wrapped container, contains itself and other items related to itself. While quite real-world and literal, that same concept when applied to node data, opens a whole new cool world of strategy to Drupal. Here's an example:
- One Event has One Venue
- One Event can have Mutiple Days
- One Event can have Multiple Sessions
- One Session can have Multiple Time Slots
- One Time Slot can have multiple Speakers.
This same thought stream can go on and on until all types of content are part of valid relationships. Do you notice the "database terminology"? One to One, One to Many? But remember, as I said above, "A wrapped container, contains itself and other items related to itself". To be truly diverse, content should be part of a valid relationsip at all times, but also be available to be reused by other related content structures.
What about unwrapped items?
By default, Drupal nodes are all orphan records. There are no content hierarchies where nodes become part of a relatioship. Taxonomy is used to "classify" nodes under a common descriptive word, but, the reality remains that these nodes are all basically orphan records (another database term). While we could think about using custom entities in Drupal to handle these orphans, that would go against my "no code" Mandatory Inventory Item mentioned above, as well as custom entities not being within a beginning developers skillset.
Changing a Drupal Site Builder into a Data Architect
Drupal Site Builders usually do not wear the hat of "data architect". Perhaps this is an error in the "Drupal Way" of doing things. If Site Builders had an in-depth knowledge of the underlying data architecture needs for the sites they provide, I think the "Drupal Way" can be vastly changed for the better. Better decisions would be made early on in the development process. Predictable results would reign true. It comes down to what should be Step One of all website projects: Documentation in the form of Information Architecture. If we are to change the definition of a site builder to include data architecture, we must define both processes together in one step.