Significant change to the Database Class

Getting a demo up and running on a new host has been very enlightening.  I have used the PEAR DB class for years because it works well and is usually available.  The host which is being used for the demo site doesn’t appear to have the PEAR DB class installed so this has motivated me to migrate the SwimTeamDBI class to make use of the builtin WordPress database access class instead of depending on PEAR.  I have considered doing this for a while but have put it off but it looks like it is time to deal with it.

My intial impression is it should not be to much of a change as my current database class abstracts the PEAR aspect away from the rest of wp-SwimTeam.  The bigger concern is the phpHtmlLib widgets which also depend on PEAR.   Those will need attention and I suspect I will end up implementing a new database abstraction class for WordPress as part of phpHtmlLib.

I have been doing a lot of work on phpHtmlLib over the last week and for the most part, it appears to be done.  All of the changes allow phpHtmlLib to now be loaded as a WordPress plugin which is much easier to support.

Standard Event functionality completed

This afternoon I committed a bunch of changes which complete (I hope) the standard event functionality.  Standard Events are the events a team would typically run at every meet.  I envision them being set up for a team’s home pool so the course should be set to match the home pool but it is up to the end user.  Once defined, the meets can be reordered to match the typical order of events.

The next phase will allow creating of meet specific meets and the standard events can be used to initialize the events for a meet.  When creating meet events, the the course for the pool is different than the standard events, the meet events will be adjusted acordingly.  This will allow a team with a home pool in meters to easily set up a meet at yards pool – if the same events are used in the same order, it will be a simple task.

Once the events are created for meet, the order can be changed on a per meet basis and other events can be added or deleted.

Started Adding Event Functionality

In order to keep a history of swim times (aka results), the events the times are associated with need to be defined.  I guess technically that isn’t true, a simple time history could be kept but as long as I am going to import times and keep them as a history, might as well associate them with a meet too.

To do this I started working on defining the events for each meet.  Since most teams swim the same events in the same order at most of their meets, I have established a “default” set of events.  I have this new functionality working now.  What is left to do is to elegantly re-order the events (since re-ordering them is inevitable) and to use them as a basis for populating the events for an actual meet.

This functionality is also the basis of Opt-in/Opt-out because I have decided to let swimmers opt in or out of individual events and as well as entire meets.  This is a need for the MacDolphins because we many of our swimmers are in year round school and since our league swims on Tuesday nigths, for some portion of our team, it is a school night.  We have a fair number of swimmers who opt out of the later events because of it being a school night.

Short Code improvement and other minor changes

Last night I committed a bunch of changes to clean up the Meet Schedule Short Code.  Previously it only worked for the current season, the optional seasonid argument was ignored.  It is now working – if the seasonid argument is not included in the short code then the active season will be used.

I also added a column for the Id in the Admin view of the seasons, swim clubs, and meets since the Id is used in the short codes.  By putting the Id in the list, there isn’t a need to drill down into the item detail to see what the Id is in order to use it in a short code.

Opt-in vs. Opt-out?

It has been pretty quiet on the development front.  Now that swim team season is in full gear, I am spending a bunch of time actually using what I have developed to date.  So far, everything is working pretty well although I definitely have some things to do.

Next on the agenda is an online scratch sheet which I will likely implement as a an opt-in or opt-out feature on a meet.  Some meets make more sense to opt out of where as others make more sense to opt in. For example, our regular season meets will be opt-out meets.  All swimmers are assumed to be participating unless they opt out.  On the other hand, our local city meet which we only have 25-30 swimmers entered in, will be an opt-in meet.  All swimmers will assumed to be not participating unless they opt in.  I believe supporting both makes the most sense and will ultimately make the system work better.  Forunately this should be a pretty simple extension to the meet functionality I implemented a few weeks ago.

Swim Meets and Swim Club Profiles

Over the last couple of days, actually since I flew home from Paris on Friday, I have added functionality to set up a swim season schedule.  To do this, I added swim club profiles and swim meets.  The swim meet functionality also includes a summary which is added to the overview page.  The summary reports the schedule for the current season, results. and lcation of the meets.

Adding swim meets is base functionality which is necessary to support online scratch sheets (need to know which meet a swimmer is scratching from) and ultimately results.  The online scratch will probably be the next thing I implement, results are a bit trickly because loading, parsing, and connecting results to swim meets and swimmers will be a fairly extensive problem.  I suspect I won’t have this working until after our season completes but you never know!

I also want to go back and visit the Team Profile functionality.  I am storing the Team Profile in the WordPress options table but now that I have Swim Club Profiles, there isn’t any reason to store the Team Profile any differently than any other Swim Club.  It isn’t urgent so I may defer that as well.

Lastly, I need to make changes to many of the classes to allow some of the methods to be called without needing a class variable first (the class::method() format).  For example – I should be able to call SwimTeamSwimmer::getAllSwimmerIds() and return an array of SwimmerIds without declaring a class variable first but right now I can’t due to the way I constructed the base level database query class.  There are a number of places where this would be really handy.

Swimmer Numbers? Swimmer Labels?

I have spent a fair amount of time this week implementing what I am now calling Swimmer Labels.  I may go back to Swimmer Numbers but I am not sure.  I’d like to call them Swimmer Ids but I have used that terminology all through the plugin for the unique MySQL record id field that changing it would be a pretty sizable task.

On the good news front, I have auto-assigment of Swimmer Labels working under several different scenarios.  I am particularly pleased with the auto-assignment of labels within an age group with a prefix – it is pretty slick if I do say so myself.  Since the MacDolphins use this format, it was particularly important to me!

CSV Export Enhanced

It is somewhat duplication of the Report Generator functionality but I went ahead and enhanced the CSV Roster Export to include the age, adjusted age, and the age group assignment.  With the clean up of the age group calculation, the information is now readily available any time a swimmer record is queried.  As such, the age and age group now appear on the detail profiled as well as a couple other places.