Desert Ice Figure Skating Club of New Mexico

Spent quite a few more hours than I wanted to on trying to make coherent the data structures for skater competitions. To some degree, I was able to get the data model correct I think. But working the input logic and display has been an utter and total nightmare.

This is not about new year's resolutions. It was about this nagging feeling that I needed to make this website serve a higher purpose. In making the data structures more coherent, I would master some subtledies in the Drupal system.

Unfortunately, my mission was not accomplished. So far.

I will attempt to briefly summarize my progress.

Methodologies

First, it is important to efficiently document my efforts on this (or any) website development. Just as it is very hard to manage a complex project from post-it notes or failing memory, it is important to concisely describe the state of a particular development, the major gaping holes, the vision of where you need to go, and the barriers. I had thought a GREAT deal about how to do this for a skating website, and part of my research led me to study the look and feel of other sites, the way data SHOULD be represented, and seek the creation of a website that is more than a collection of static pages.

I am conflicted on this for the case of this one website. Certainly, making a number of static pages is easier. But it just doesn't seem right, for a variety of reasons. Coherence is massively difficult, for one thing. If a schedule changes in one place, it may be necessary to make minor adjustments in five other places. If you miss one, and continue to make such mistakes, the website is full of flakiness and takes on the ad hoc pocked-markedness of many amateur websites. I wanted a much more professional look and feel, because we need all the help we can get.

So this led me to design a relational database framework, that I will describe next.

Data Structures

The approach Drupal uses makes it easy to represent your data in a relational database form (it's built on MySQL of course, which helps). This can be done by creating a number of content types, and then carefully designing the fields to link to fields in other content types.

This picture shows a number of data structures, each of which is represented by a content type. We see, for example, that the rink is a type of content. If you visit the front page of this website, there is a clickable link of these rinks, which are laboriously entered, but are easily linked to from other content types, such as competition. Now, when we input a competition, we coherently do several things:

• Link a competition to a rink. Obviously, competitions require ice, which means they are at a rink. Very obvious, but if we enter a competition in the input for the website, we would at least need to mention the rink. But I wanted to go "the extra mile" and provide a full description of the link, provide information to help people find it, etc. If we were to statically do this for each competition, it would be inconsistent probably. By separating rink as its own datatype, we can do some very nice things (I'll probably never do) such as link hotel/restaurant recommendations (as a courtesy for skater families traveling to the rink), etc.

• Link the competition to the club calendar. We could obviously build a static calendar, but it's much, much better to have it so that when you represent the data ONCE, it's effect ripples throughout the website so that anything depending on it will also be correct.
• Provide a hook to integrate a calendar for the events at the competition. In other words, my objective in constructing a web page for a competition is to automatically capture the key data, to include the calendar of all events, the location, etc. So, to do this, we define another content type (competition event).

I won't further belabor the details of these. I had reformulated this several times, and spent a lot of time refining them to what is shown here. At the moment I write this, some of the input for this website is still broken relative to the form I show here.

Page Display Objectives

In the spirit of "model-view-controller", we follow a discipline in which we first define the "model"(the structure of data), the "view" (the organization, filtering, extraction, and display), and finally the "controller" (the logic that stokes the model and view). So, the next figure is a sketch of the view I want to achieve.

One test case I am using at this writing is the Broadmoor 2008 competition (http://difsc.org/content/broadmoor-competition-2008). In this case, I am trying to bring together a lot of the information that surrounds a skating competition (the rink, the skaters participating, the schedule of events, pictures, program book information, scoring sheets / results, etc.). I am a long way from that.

Barriers

So I feel that I am barely getting there with the "model". I must conclude that doing anything non-trivial with Drupal exposes an exponentially more difficult learning curve. If you need anything that cannot be done "out-of-the-box" from either Drupal or any number of installed modules (chosen from the thousands that there are) requires that you get ensconced in the deep underworkings of Drupal.

For example, entering a competitive event (like a Preliminary Compulsory Group B) at a particular competition (like Broadmoor 2008) means you open up an input form from Drupal for the competitive event. You would ideally want to select from a number of previously input competitions, and we are easily able to do that by using a field that supports "node reference". So it is now straightforward to build the competition calendar by first inputting a competition, which links to a rink and master calendar, and then entering all the individual competition events, which link to the competition as well as the master calendar.

It is much harder to enter a competition performance. A "competition performance" is an activity for a particular skater (who is also a member of the website), performed in a specific competition event at a specific competition held at a specific rink. So, it is really only necessary in the input of competition performance the skater (user) and link the skater to the competition event. We have an input for the final score, a ranking amongst other skaters in the same event (we don't input the performances of non-DIFSC skaters, obviously). We can later define other content (to include the music used, pictures/videos of the skater, pictures of the score sheets), and connect them to this single competition performance. But even in just trying to do the simplest thing, we hit a strong barrier. Selecting a skater is easy. We have defined users to have "roles", and "skater" is a role (just like "parent", "administrator", "club official", "coach"). So I can easily make a pull-down menu to pick a single skater. The pull-down ONLY has skaters, so I don't have to see the clutter of dozens of non-skaters. But if we try to pick the competition event we find it necessary to pick through a much larger list of events. For even a single competition, DIFSC might participate in several dozen events. For all competitions across all years, the list grows to hundreds of rows, much too difficult to manage. So we then need to expand the data entry for competition performance to include the competition. If we know the competition, we can restrict in theory the universal of selectable events to a much smaller list associated with a single competition. This is where I hit a huge barrier, that in order to solve, requires me to understand the guts of Drupal in much more detail than I ever wanted to. The problem is not in linking a performance to a competition, that is really easy. It's not in linking a performance to a competition event, that is also really easy. What is hard is to chain the two together, so that choosing a competition automatically collapses the list of the events to only those that occurred at the one competition of interest.

Other barriers of course will include integrating a list of skaters at the competition with the display of the page. Since I had to hook in the input of competition to performance (this is how I hope to winnow down the list), I should be able to exploit that to get a list of skaters. (maybe this is now "easy" if I define a view and embed it in the page -- this is "Drupal speak").

Anyway, I'll stop for now. I hope my attempts to document are not an exercise in futility. In the future hopefully I will be able to understand these notes. I apparently must keep working with Drupal in enough depth and frequency to keep up with the knowledge in addition to maintaining websites such as difsc.