As I mentioned in the introduction to this new structure, capturing the increased level of detail afforded by the new structure requires an interface capable of recording a sequence of events associated with quasi-independent contexts, sometimes tied to a root event. Although these evnets need not be recorded simultanteously, the interface should respond quickly enough to give the user the impression of near-simultaneity.
Therefore, while a substantial percentage of the events recorded will be associated with the batter, it seems to me desireable to display on the same page the current status of the three bases, including the capability to enter an event associated with a runner on that base. This led me to envision a page patrtitioned something like the page at right.
There are two primary ways to go about partitioning an html page in this manner: tables and frames. The big advantage that frames have has to do with treating the partitioned areas of the page as, in effect, independent pages. That is why they are frequently used on the web to provide a mechanism for selecting from a large menu of options, because selection of one of those options does not require that menu frame to be re-populated: only the target frame is re-drawn. Unfortunately frames are also tempermental, and seem not to be used as frequently as expected in contexts in which the html is being generated, as opposed to those in which a root html page calls standalone cgi scripts that return the selected output. In my experiments with frames here, a functional set of frames that I had set up in an html document were not displayed when I included the same code in a subroutine in BB_APP_INTERFACE. Rather than spending time diagnosing the problem, I decided to use tables instead. I may well return to this at a later point, but at this point I was more concerned with moving into some of the upcoming material. In this context, the use of tables does not represent a significant burden, as the application is envisioned as residing on a local are network with a likely minimum bandwidth of 10 Mbps rather than being required to be functional for clients using a dial-up connection with approximately 200 times less bandwidth. If such were the case, I might develop a workaround that sandwiched an enternal html file calling cgi scripts in between the generated menu and the footer table. As that is not the case, I would rather not adopt something that strikes me as being something of a kludge.
The html tables that I have used in this document have to this point been fairly simple. When I have implemented more complex structures it has been through nesting simple structures. While there is merit in this approach, at some point it will break down. Browsers render tables in accordance to a set of rules of precedence, and at some point using nested tables it will be impossible to produce a page in the manner desired, regardless of how much the html intended to produce the output seems to make sense. Therefore, in this section I decided to start making use of some of the most sophisticated formatting elements in the table definition. In this specific circumstance I used the rowspan argument in the definition of the first table cell, the upper left-hand cell in the table, to tell it to span three rows.
<table width="95%" border="1"> <tr> <td rowspan="3">HI <td>HI <tr><td>HI <tr><td>HI </table>This little snippet produces a page that looks like this
At this point I started building the basic form that will be used to enter an at bat. One of the items that will be on the form is, of course, a select box to allow the batter for the at bat to be chosen. In previous entry scenarios I had simply listed all of the players in that select box, which is fine when one is dealing with a test table of only a few records but more than a little bit unwieldy when the source table contains a couple of hundred names. It also does not make a whole lot of sense, given that the only players I am interested in here are those associated with the team at bat. Therefore, I need to add a database statement to retrieve the relevant players. A reader with a sharp eye might well say "Wait a minuite ... you did that in the last chapter!" As is generally the case, such users would be right. In this context, however, I need to have the first name and the last name concantenated so I can feed that string and the participant code in the result set to the make_hash() subroutine and run the resultant hashref into the sel_box() subroutine. Therefore I added the preparation of the $part_game statement handle.
##statement to return the players associated with a given team in a form suitable to be turned into a hash and fed to sel_box
my $part_game=$dbh->prepare("select part_fname || ' ' || part_lname,participant_id from participant where team=?");
and added a reference to it in the %db_hash. I could have gotten the same result if I had looped through the result set from $part_team and concantenated the two names, but that would have added a few execution cycles, which I wanted to avoid. On the other hand, defining such statement handles always requires system resources, and it is worth remembering that the ralphzilla server itself is a 100 Mhz pentium with 64 Mb of RAM. It is within the realm of possibility that at some point it will be necessary to prune back some of these statement handles, relying instead on the manipulation of the result sets from relatively few such to produce the desired output.
The current state of the system had only a few players entered, and of those only two or three assigned to teams. As I have not yet put into place a mechanism to specify the relevant team, I have explicitly assigned the id for one of the teams that does have assigned players (Defenders of Humanity, id "007") to a scalar that I use to retrieve a set of players
my $team='007';
my $sth=$$db{'participants_team_game'};
$$sth->execute($team);
my $players=make_hash($$sth);
and I can create a bare-bones version of the interface with the following code
$$r->print("<center><table width='95%' border='1' $colors>");
$$r->print('<tr>');
$$r->print('<td rowspan="3"><center><h2>At Bat</h2></center><br><br><br>');
$$r->print("<form action='/bb_app/league/la-store' method='post'>");
$$r->print('Batter:');
sel_box($players,$r,'batter','','','');
$$r->print("<br>");
$$r->print("Event:");
sel_box($$select[0],$r,'ab_event','','',' ');
$$r->print("<center><input type='submit' name='submit' value='Submit_Event'></center>");
$$r->print("</form>");
$$r->print('<td><center><h2>First Base</h2></center>');
$$r->print("Runner:<br>");
$$r->print("Event:");
$$r->print('<tr><td><center><h2>Second Base</h2></center>');
$$r->print("Runner:<br>");
$$r->print("Event:");
$$r->print('<tr><td><center><h2>Third Base</h2></center>');
$$r->print("Runner:<br>");
$$r->print("Event:");
$$r->print('</table></center>');
which produces a page that looks like this:
In the next sub-sub-chapter I will begin to output pages that incorporate javascript.