Understanding Nothing

Yesterday we built our first page. Because we had to set up some database mappings it may have seemed more complicated that it actually was. If we wanted to add another page today that viewed a CD in a different way, all we would have to do is add another line (7) to the config_info in Site.pm:

5
6
7
8

  sub config_info {qq{
      /view/cd gets MDB::CD
      /show/cd gets MDB::CD
  }}

And now we just create another template in page/show/cd.tt.

Today we’ll build another similar page, for artist details.

In the database schema we had yesterday, we assumed that “artist” was a field in the CD table. In reality this would usually be a foreign key to an artist table, with, say, ‘artistid’ and ‘name’ columns. So let’s migrate our system to that.

First, we create the MDB::Artist class, telling it what table the data lives in, and setting up the has many relationship back to the CDs by this artist:

1
2
3
4
5
6
7
8
9

  package MDB::Artist;
 
  use base 'MDB::DBI';
 
  __PACKAGE__->set_up_table('artist');
  __PACKAGE__->has_many(cds => 'MDB::CD');
 
  1;
</code>

Then we let the CD class know that its ‘artist’ column doesn’t contain the artist name, but rather a pointer to the artist table (line 7):

1
2
3
4
5
6
7
8
9

  package MDB::CD;
 
  use base 'MDB::DBI';
 
  __PACKAGE__->set_up_table('cd');
  __PACKAGE__->has_many(tracks => 'MDB::Track');
  __PACKAGE__->has_a(artist => 'MDB::Artist')
 
  1;

Now, any time we ask a cd for its artist we’ll get back an MDB::Artist object instead of a plain string,

So, in our template, where we previously had

<h2>[% cd.artist %]</h2>

we now need

<h2>[% cd.artist.name %]</h2>

And now we can build our artist page. Again it’s very simple. We just add it to our config_info (line 8):

5
6
7
8
9

  sub config_info {qq{
      /view/cd gets MDB::CD
      /show/cd gets MDB::CD
      /show/artist gets MDB::Artist
  }}

And now we can create our artist template, page/show/artist.tt:

  [% META browser_title = "Artist details" %]
  <h1>[% artist.name %]</h1>
  <p>CDs:
     <ul>
       [% FOREACH cd = artist.cds.sort('year') %]
       <li>
         <a href="/show/cd/[% cd.id %]">[% cd.title %]</a>
       </li>
       [% END %]
     </ul>
  </p>

And of course we should really go back to our CD template and link the artist name to their own page:

    <h2>
      <a href="/show/artist/[% cd.artist.id %]">[% cd.artist.name %]</a>
    </h2>

And now we have a simple browsing mechanism from a CD to its artist to all that artist’s CDs.

Scott does the math(s) with all the 9s. Reminds me of the If 99% Were Good Enough lists. (I can’t find the one I used to have, but this one is the same idea). Of course, it wouldn’t surprise me in the slightest if every one of the items on this list actually happened; things like “20,000 incorrect drug prescriptions will be written this year” not only sound plausible, but probably understated to me…

The problems of course, are that most people believe that 99% is good enough, and most businesses don’t even strive for anything that good. And that every extra 9 you want usually costs about 10 times as much as the previous one, and most people can’t justify the investment.

At BlackStar, I like to think that the extra 9s easily paid off in customer loyalty, industry awareness, and press coverage.

Day 13 of Mark’s Accessibility Tips is “Include Real Links”.

This is a personal bugbear, but not for any of the reasons Mark lists. Me, I hate javascript links because I use Mozilla with my middle mouse button bound to “open link in new tab”. Which, of course, only works with real links. JavaScript links don’t want to open in a new tab for me, they usually want to spawn a pop-up window. But I don’t want lots of windows. That’s why I switched to Mozilla. Now I can still have lots of pages open at once without my windows explorer bar being completely unreadable.

Unless you decide that what I really want is popups.