sfmagic.org Rewrite: Planning Data Entry
.Sadly, I’m not quite going to finish a drop-in replacement for the current sfmagic.org codebase by my deadline of tomorrow. I’m close, and I think I have everything except the data entry portion, which I’ll lay out in this post.
The three major enhancements over the old version are: do all of the entry for a tournament on a single page instead of two pages; handle multiple tournaments on a single page; handle head-to-head results. The current version requires me to enter the details about a tournament, then wait, then enter the results for that tournament. The new version will handle it all on one page.
Ultimately, what I want to do is to pass the server a big JSON data object containing an array of dictionaries, each of which details everything about an individual tournament. To do that, I need to have JavaScript read the form fields, put them into this data construct, then pass them to the server asynchronously and have Python decode them and put the right results into the right database table, then return a summary of what it’s done for verification.
The page will start with the form for a single tournament on it, but may expand to hold as many of these as is necessary. At the top of each section will be the information about the tournament: date, id, number of players, seeding type, format, etc. This will go into the tournament_data dictionary.
Once that’s been completed, it isn’t submitted but the information in it is used to create a list of slots, each of which will have a player and their results. Each player name input will be a select dropdown that has all the current players. (Eventually it will also have an add player option which will allow in-place addition of players without a page refresh).
In the old version, this would be where I would enter each player’s game and match records. Not in this version, as these will be derived from the results data below. The important fields for this are the player names, which as well as noting which players were in the tournament also notes their draft order, and the first pick for each player. The first pick fields will have autocomplete for rare names, just as they do now.
The game and match record fields will be there, but disabled and empty.
Below that will be the pairings for each round. Here, a lot of JavaScript will be required, as it needs to essentially understand pairings within a tournament to be useful. Each round will have a number of matches, and I’ll input the data about those matches into the respective fields. Once I’m done with a round, the JavaScript will give its guess at what the pairings for the next round are. I’ll be able to change that if necessary.
After all the rounds are entered, hitting submit will update the results line in the results section for each player with their results. It will also put together a result dictionary for each match in the tournament.
When the form is submitted, first the tournament data will be submitted—or that will happen asynchronously while I’m entering other results—, then the results, then the head-to-head results. Each of these chunks eill go into a JSON object, whcih will be passed to the server, and then it’ll do the database updating, followed by a callback showing the results, which will be included in the response to the asynchronous request.
That’s the plan. The hardest part will probably be the JavaScript powering the results, as it might be as complicated as something that basically runs the tournament for you. For one thing, it would certainly calculate tiebreakers and so on.
Hopefully I’ll get that done this weekend. I might leave some of the JavaScript enhancements out, but I hope to have something functional after this weekend. And then I can start entering the results—the backlog goes as far back as August, so every increase in ease-of-use for the entry section will pay off.
16 Jan 2008 at 02:49
Data entry? Do you have the data electronically? Surely you’re not planning to enter it by hand?