The first cut at an overall data structure was a list
YearRow instances. Each
would be a container for
instances, one per valid month.
However, there are certain things we need to know about
the months, such as the month number (e.g.,
'04'). So the
was invented, with an instance holding one
BirdNoteSet and ancillary information such as
the month number and the file name of the month page.
YearRow would then be a container for
MonthCell instances, one per valid month.
The next problem was connecting up the navigation links
between month pages. Clearly, when rendering a month
page, we must know the URL of the
know these URLs? Three approaches were considered:
MonthCell class have
attributes that hold the previous/next links;
initialize them to
Then, after all the
instances are created, make a serial pass through
them and link them up into a bidirectional linked
Finally, render each
HTML in any old order, using the stored previous/next
attributes to set up its navigation.
The aesthetic objection to this approach was that the
MonthCell objects depend on an
external mechanism to set up their linking.
Logically, the information required to find a month's
neighbors should reside at a higher organizational
Define a global function called something like
neighbors() that finds the previous/next
neighbors, given a year and month. This function
would walk through the
starting at the given month, and working backwards
and forwards to find the nearest neighbors.
The objection to this approach is that the
yearList must then be global, or be passed
around through many levels.
At this point, the author felt that a third class was
manages the overall sequence of years and months.
It can traverse the years in reverse chronological order to build the index table with the most recent years first.
It is the obvious place for logic that can find the neighbors of any month.