[CompInaBox-discuss] CompInaBox -- Version Two emerging details and questions...

[Eric D N. <nie...@MI...>]

So I've been rolling on the rewrite of the SlidingDoors module the past week or
so and I suspect its going to evolve into a complete rewrite of most of CIB
over the summer.

As mentioned before there are two main goals for this rewrite:
  1.  Streamline the registration process/remove navigation limitations
  2.  Fold the per-competition databases back into the central DB

Architecture
  I'm looking at a rather sophisticated underlying architecture compared to the
old CIB.  The old CIB is probably best classified as a Page Controller with a
relatively poor (as in non-rich) Domain Model with builtin DAO.  The new system
is moving to a Front Controller based system, a richer Domain Model and
seperated data mappers.  Many of these changes are partially driven by
testability concerns and os far the new system appears to be shaping up in a
good way.  I've almost finished the first page view -- having built most of the
infrastructure, including some of the generic error handlers (database down,
invalid competition, invalid command, etc).  I don't havge a good handle on the
View component yet, but it will be some form of Template View.  Unsure of how
chrome/theming will be handled .

The Front Controller itself is slightly more complex than the normal Front
Controller, but less so than my version last summer when I had it fallback to
the old style Page Controllers if no "Module Controller" claimed the request. 
(Last year was an incremental plan, this year is a ground-up plan).

Since PHP is loaded anew on every invocation, I didn't want to a huge mapping
file like the Java world would tend to use.  Thus the top level Front
Controller maps the request against a series of regexps to find which "Module"
to invoke --  SlidingDoors, SlidingDoorsAdmin, Results, Calendar, TeamAdmin,
etc.  When the Module is selected the associated Request and Context helper
objects are "upgraded" to hold Module specific information as needed (database
references, phrasebooks, etc).  The Module Controller then basically repeats
the process to select either a Command or an Application Controller.  Commands
handle and updates to the underlying system and retrieval of information from
the DB into the Context for use by the selected view.  Application Controllers
are used when there is a "wizard" type series of pages (such as registration,
result importing, or check entering) with possibly complex state changes.  It
is here that I hope to allow the more flexible navigation within the
registration process.

Development plan --
  I'm starting with the URL /register/[index[.php]/] its a non-existing page on
the current CIB.  But it will be a simple list of open competitions with some
supporting data.  Something along the lines of
http://www.ballroomregistrar.com/comp_summary.php?type=OPEN

As its a simple page with no "actions" associated with it, only retrieiving a
list from the DB.  This is almost complete (without chrome).

  Next will be navigating from this index page to a competition registration
home page.  Ie something like
http://www.ballroomregistrar.com/register/MIT06/
However the information content will be restructed to something like
http://www.mit.edu/~nielsene/CIB/comp_index_v2.html
designed to handle an arbitrary number of deadlines, arbitrary number of contact
names/emails, etc.  As well as being less wordy.

  Step 3 will be the admin page for the comp home page -- ie the plan rewrite is
including the folding in of PrepStep into SlidingDoors at every step along the
way.  This first admin page will allow: Editting the Competition Name, Dates,
deadlines, and contact information and, of course, requires authentication. 
Once complete it will be hooked up to an option from the list page (and other
places as appropriate) for creating a new competition.

 Step four will be either more comp setup or straight into the comp registration
 process depending on timing issues.

OK, if you've read this far, thank you! :)  Now for the questions that are
emerging --
  I hope to merge the per-competition databases into the central database.  This
should make no difference to end-users, but will make setting up a competition
much easier.  It might have some preformence implications, but I can deal with
those in a variety of ways, should it become an issue.  However it does
generate two issues:
  1)  Close name matching -- the library of names will be much larger as instead
of matching against just one competition it will match against all people.  This
is probably a good thing, assuming I handle it right (big assumption).  I'm
still NOT assuming/enforcing user-accounts to register and thus non-users will
get auto-generated passwords for each competition.  (Required if some schools
use different bulk registrars, etc).  Can anyone think of other issues here?

  2) "Unixname" all competitions currently have a "unixname" this is the
competition name that appears in the URL for register/* and stats/*.  The
Unixname is currently the primary key in the comps table.  However, this is now
exposed in three places:  results importing, beta PrepStep, and the Calendar. 
Most end-users entering data in the calendar or in PrepStep would have no clue
as to why/what they should enter for this for their event.  Thus I think I will
be demoting the unixname from the primary key to a candidate key.  (The calendar
app didn't need a unixname at all in the first place. neither did the
result_tracker.... only hosted competitions really "needed" it as it was the
name of the per-comp databases and part of the abosolute path to the scripts --
as the new system doesn't need either at a physical level I could get rid of it
completely.
   However, I still need something to use in links.  I can pick the "comp
abbreviation" during result importation, I could assign one when approving
non-hosted calendar entries, I could assign one when approving a configured
competition prior to opening registration, etc and thus not really change the
existing system/URLs.
   I could change to using a number (ie register/12/); I personally hate the way
that looks and how it doesn't help the user know which competition a link may
bring them to, but its an option.  I could change to using the full competition
name, URL-encoded, but that's likely to be messy, long, and annoying as heck.
   Any other thoughts?

Thanks

Eric