This post describes by example, a very efficient Drupal implementation methodology that involves first generating the expected data for your system then only using Drupal to manipulate the data. I simplified the implementation of a Drupal based facility booking system by pre-populating the booking entities with all possible booking time slots for the next two years. The only functionality I had to “program” using Drupal was updating the booking status field to booked when a booking was made.
A client needed residents of a block of flats to be able to book four facilities, a squash court, boardroom, tennis court and clubhouse. Each facility had set bookable time slots from a one hour slots to full day. I am not a full-time Drupal developer so I avoid writing code that I know I will not be able to maintain. For me maintainable sites translates to using popular and supported modules such as Views, Rules and Date to implement functionality before turning to less supported but feature specific modules. I did evaluate a some modules that provide booking functionality in one way or another. This included MERCI, Resource Booking, Agreservations and Booking Time Slotsg to name a few. My preferred implementation methodology is more a case of me sticking to my strengths than a reflection on the quality of booking modules.
After several days trying all manner of combination of modules, I failed spectacularly to create a booking system. Some modules used in this fruitless effort included Date, Entity reference, Relation and Field Collection. The best way to illustrate why I failed and how simple my eventual implementation was is to list all the things I didn’t have to implement. I have also included all the things the users will not have to do.
- No data will be captured thus no entity forms to theme.
- No validation of dates or time slots
- No entity references including taxonomies were defined. No in-line forms for time slot entities
- Creating a sensible user interface involving a few different related entities was not necessary.
- No conditional fields, i.e. when a user selects squash court, displaying available timeslots for squash court
- No relationships and contextual filters needed to be defined in the View
Solution
Since I knew that each facility can be booked for set time slots, I worked out all the booking slots available for the year. To be on the safe side I catered for two years of bookings. This came to 10 000 slots of for all the facilities. This architecture borrows from date dimension concepts in data warehousing. The date dimension is a pre-populated table with historical and future dates. To generate the time slots I created two tables. One with all time slots per facility. The second was just a list of all dates for the next two years.
The second step was to run a SQL statement without a JOIN specified. For each day I got all the available slots per facility. I imported the data as a once off the entity using Feeds and Feeds entity processor.
SELECT booking_date ,resource as facility ,start_time ,end_timeFROM booking_date ,facilities
The ECK entity model to store all the booking slots was very simple. It had with six fields.
| Field | Field Type | Description |
|---|---|---|
| Booking Date | Date | Booking date |
| Facility | List (text) | Facility being booked. |
| Start Time | List (integer) | Starting time |
| End Time | List (integer) | End booking time |
| Booking Status | List (text) | Two possible values, booked or not booked |
| Booked by | Integer | User ID of person booking facility |
The only logic I needed to “program” into Drupal was logic to update a slot to being booked or not booked. I used Rules and Rules Link to create a Rule Link that assigned the Booked by field to the person doing the booking. I used the Set a data value action to update the Booked by field to current user and the “Booking-status” field to booked. Both actions were performed within the same rule.
The final step was to create a View from the booking entity. I added exposed filters to allows users to select a booking date and facility they wanted to book. The rule link displayed as a button next to each slot. I turned on caching turned on performance was very good.
##ConclusionPre-populating entities removes the needed to facilitate and validate data entry. Off course it is only possible when the number of possible entities is predictable, reasonable in number and calculable. Even if the number of entities is large, an automated process can be set up to import a few months of data at a time. Off the top of my head I can imagine how this data first approach can used for:
- Attendance registers for committees, boards and schools.
- Ticketing application for venues that sell numbered seats
- Restaurant table bookings
- Simple online shops
You are limited by your imagination. The only logic you have to program is update entity columns. The Rules in conjunction with the Rules Link modules make this possible. I think of data first and then how I can use Drupal to manipulate the data. Read this post using Views Database Connector (VDC) to display data in external database for further information on how I use as a data platform.