Homepage ->  Individual Weblogs -> Kevin Lawrence  -> In which we design the score card

March 15, 2007 - In which we design the score card

In the previous installment, I wrote the code that implements rule 2.1.1. For rule 2.1.2, I finally start to add up some scores and show them in the score card.

2.1.2 Except when a strike is scored, the number of pins knocked down by the player’s first delivery is to be marked in the small square in the upper left-hand corner of that frame, and the number of pins knocked down by the player’s second delivery is to be marked in the upper right-hand corner. If none of the standing pins are knocked down by the second delivery in the frame, the score sheet shall be marked with a (-). The count for the two deliveries in the frame shall be recorded immediately.

The rules don't actually say that I should add the scores up but the diagram, in a 1000 words or less, paints the picture for me.

I still don't know what a strike is but that business about marking deliveries in small squares sounds like something we can make a start on. Many of my TDDing colleagues prefer to complete all the domain objects before they start on the user interface, but I prefer to hook up a version of the UI as soon as I can for several reasons:

1. It allows the UI designers to see how their designs work with real data. Early integration with the UI helps everyone see how it all fits together and can highlight areas of the system that are under-specified.
2. The way that the UI 'wants' to access the domain objects can influence the API. If you leave the UI until last, you often find that the domain objects have to be modified to make them more accessible. It's better to discover things like that early on.

Even though I don't expect to get the UI - or the API that the UI will use - right first time, getting a version of it out there early will give me time to refine it in future iterations.

A First Draft of the Score Card

I have chosen to render the score card as HTML and this seems like a good excuse to try out the JavaServer Pages Standard Tag Library (JSTL). I have always been a little disappointed with JSP - it has never felt as natural to use as other templating technologies like ERB, Velocity or even ASP.NET - but with JSTL, it finally seems to be moving the right direction.

Here's a first draft of what I think the JSTL code will look like:

    <table>

      <tr>
        <c:forEach varStatus='loop' items='${game.frames}'>
          <td colspan='2'>${loop.count}</td>
        </c:forEach>
      </tr>

      <tr>
        <c:forEach var='frame' items='${game.frames}'>
          <td>${frame.firstBall}</td>
          <td>${frame.secondBall}</td>
        </c:forEach>
      </tr>

      <tr>
        <c:forEach var='frame' items='${game.frames}'>
          <td colspan='2'>${frame.score}</td>
        </c:forEach>
      </tr>

    </table>
    

The repeated loops are ugly (no doubt someone will show us how beautiful this would be in Ruby) but this first draft should be enough to start writing the domain code and for our web designers to work their magic.

On to the model code that will generate the correct numbers for the score card...

Posted by Kevin Lawrence at March 15, 2007 01:02 PM

Trackback Pings

TrackBack URL for this entry:

Comments

Post a comment

W3C link checker    Powered by Movable Type 3.16
This weblog is licensed under a Creative Commons License.
Agitar, Agitator, Software Agitation, Open Quality, and Quality Level Agreement are trademarks of Agitar Software, Inc.

Terms of Use