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:
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  :)