I’ve spent today tuning up the PaGES framework in anticipation of its new use as a frontend to Banner. In order for that to work, the PHP framework really needs to be a well-tuned, well-documented, well-tested machine. We don’t want to get into another Financial Aid web forms support nightmare. The improvements on the PaGES framwork focused on three areas:
- Eliminate use of cacophony, PEAR, and MiddSettings
- Comment and test everything
- Use the new PHP 5.2 features in the SPL and PDO
The first point is an ongoing process. In order to be truly self reliant, we need to get rid of anything that references PEAR and the cacophony project does this all over the place. Fortunately, PaGES was started with some of this in mind and only reverts to relying on PEAR in areas where significant redevelopment is necessary, most notably the reliance on MAuthRA, which uses PEAR::DB_DataObject and PEAR::DB_ldap.
PaGES will continue to rely on MAuthRA for the time being, but anything else is being ported. This means that utility classes, like the Exceptions in cacophony and HTTPQuery need to be redeveloped in PaGES, though this is fairly minor work. I’m also killing off the centralized Singleton class, MiddSettings, and moving any settings into class constants and variables. Includes are done through use of the __autoload magic function in PHP rather than static function calls to MiddSettings::involve.
It’s also important that PaGES have a really solid foundation of code comments and unit tests. The idea for PaGES is that it will be supportable by a team of 2-5 developers within LIS and extensible to meet ongoing needs. For that to work, the library needs to be documented far better than the cacophony project ever was. Unit tests help here too by letting us run a barrage of tests against the whole framework after any change is made to the code base.
The last point focuses on what will be the replacement for some of the utility functionality I was using in PEAR: the standard PHP library functions for container objects and PHP data objects as an engine on top of which the PaGES database abstraction layer will sit. The PHP development team has really done some good work into having a more sensible (though still silly) core library of functions available for PHP 5, so we might as well use them. Hopefully by PHP 6 they’ll have killed off all non-PDO database functions so we won’t have 4 different ways to make a MySQL connection in the core code base. But probably not.
I focused today on porting some of the core classes of the PaGES framework into the not-relying-on-MiddSettings version of the framework with classes like Breadcrumb, Stylesheet, and Header included. The rest of the core classes should more along quickly with more work required for the forms related classes.
I spent most of last week putting together a spreadsheet of the non-sports-related questions for Athletics Recruiting and their estimated positions in the database schema. There are around 300 affected columns in Banner for these questions and many of the questions, like parent/guardian questions, allow you to add multiple records (i.e. you can continue to dump in parent/guardian information for as many parents/guardians as you like). Of these, there are approximately 10 for which we don’t yet have a column in the database.
There is also the case of many columns for which we don’t yet have a description code. For example, when you add a telephone number you have to specify its type code. There is a type code for “home phone”, but there is a concern that we may want to specify a specific type code for the Athletics Recruiting web front end so that it doesn’t interfere with recruit reporting elsewhere. Hopefully we can find a solution that doesn’t require us going through DIG for approval.
I’d say I’m about 65% done with this spreadsheet with work halted for the moment while I await a revised database schema from Heidi with the changes applied from our discussion last week. We met and made some changes to the original schema to reflect the fact that we’d be gathering data for multiple sports per application on the web form. This was not possible with the original schema which was designed for the tape load process where we only had to worry about a single sport per applicant. There are a number of other revisions, like a way to associate a coach with a sport and adding a relation type field to the relations table for parent, guardians and siblings.
I recommend paging through the Software Engineering for Internet Applications book. It’s courseware from an MIT course about designing a web application framework for an online community. There is really good and specific information in there about how to use up user databases and also good philosophical information about how to design for communities. The section on usability is particularly good.