Title: GameOn!
Author: Ken Goldenberg
Abstract:
A web-based system that can manage the "pre-game" administrative needs
of my hockey team.
What:
Skaters "on the roster" will be able to use a web-based tool to
announce that they can/cannot attend the next game. If "subs" are
invited to a game, they will also be able to respond yes/no (I don't
know is the worst thing you can tell a captain of a hockey team w.r.t
planning)
There will be a simple bulletin board interface where team members can
discuss anything of general interest before a game. For this
initial version there will not be any administrative controls to
moderate these discussions.
There will be at least a simple administrative interface for sending
pre-game reminder email, inviting subs, and printing (as a PDF) a
league acceptable game roster (based on the current responses) which
will be brought to the game
The web site needs to render properly on at least Mozilla/IE and my
Treo. Rendering properly on other handheld devices (Blackberry) would
be nice but since I have limited access, is not a requirement.
Why:
My hockey team has a feast-or-famine problem. If less than 9
skaters show for a game, everyone is tired and unhappy. More than
15 skaters (3 full lines) is a nightmare (the most famous event in team
history is the game that 17 skaters attended in which a fight broke out
on the bench over ice time) The "ideal" is about 12
skaters/game. Summers (vacations) are particularly bad.
Trying to manage "who's coming" via email has meant a fair amount of
accounting work and doesn't provide immediate feedback to the
team. It's easier to bail on a game if you don't know that there
are only six other skaters.
How:
My initial impulse would be to store data in an RDBMS but for
simplicity w.r.t install on nice (and course relevance) I'm thinking of
storing all persistent data (roster, schedule, games, BB comments) in
XML files.
Ultimately transactions should be pretty simple (skaters append
comments for "bulletin board", and "flip a bit" for Y/N for a game) but
without a DB enforcing locking, I'll need to handle that manually since
50% of the "responses" will be immediately after the email is sent.
Other than the above "business logic" the problem becomes a
straightforward "transformation" to display the current data in an
straightforward way including positional breakdowns (ie how many
defencemen are coming now, since we never seem to have enough)
On the administrative side, a form+JavaMail should make quick work of
sending the "roster players" email, but selecting subs/sending sub
email will require a bit of work. If the player/game info is
stored as XML, it's less critical to have an admin interface to
add/edit this data, but it would be nice given the time. Baring
that, I'd want to at least validate the XML via a RelaxNG schema.
I anticipate using Java for the "business logic", XSLT to do most of
the transformations to XHTML and handling the PDF roster via
XSL-FO. I keep thinking that Cocoon would tie it all together,
but I have a bit more research to do in this regard to really
understand the implications of choosing the platform. I need to learn a
bit more XSL-FO to get the PDF output to look anything more than
"passable" and every time I've dipped into XSLT in this class I've
learned that my ignorance is pretty daunting. I've been messing
around with RelaxNG for the past few weeks (work project) and think
that writing a schema will be pretty trivial. I haven't looked
into JAXP support of RNG but how bad can it be? Worst case, I'll
translate it to .XSD via Trang :)
Questions:
Basically I have a technical question and a scope/grading question:
Is there an accepted way to handle different "output platforms" (in my
case desktop browser vs handheld)? Left to my own devices, I'd
think to check the useragent and select a different stylesheet...
I can scope the project at the following levels:
- Minimum-acceptable design to go into the Summer hockey season
(more or less what's above)
- Fully-capable admin UI (to give access to someone else to run a
team w/o expecting them to modify any XML to start the season)
- The above plus a "team portal" ie uploadable pictures/game
summaries, updatable stats, etc (What I'd add if I wanted to sell this
to someone to run a team) Basically bells and whistles that I don't
care about (old piks/stats etc are REALLY sad looking) but that would
be needed to sell this.
- The above for multiple teams (if I wanted to sell this to the
league) Simple in practice, more issues (conflicts with players on more
than one team) and the expected bells and whistles at this level will
take me more than a month to do...
All but the last item I think I can do without TOO much trouble.
I don't have much interest in the "portal" because I don't think I'd
use it. The Admin features aren't really needed for the short
term, but WOULD add quite a bit of polish to the system.
What I'm looking for is some scope advice. 33% more weight than
the other projects is a start, but any feedback would be
appreciated. For that matter, seeing a graded Q9 for Proj3 would
really help :)