I think I’m going to move this to a once-a-week posting thing in theory since that’s what it’s already become in reality. Sunday seems like a good time for this too, because I should have all of the code updates for Monday’s push done by now and with nobody else here, I can usually finish up all of my tasks for the day and still have a bit of breathing room at the end, as happened today!
Athletics Recruiting
I’ve finished the Data Analysis, which should really have been completed before any work on the project was started. There are about 700 columns touched by the Web Front End, excluding when the form repeats like when the user enters more than one sport. A single user could bind to more than 1000 Banner columns in the course of filling this thing out. It will be interesting to see if any actually do.
The big trick with this will still be making sure that the default values we use for type codes, such as the home phone number of the recruit, don’t conflict with anything else Admissions is doing. We’ll also have to do some work with the initial population of tables like the questionnaire questions, and person and relative codes that don’t exist yet.
We’ve also made the decision to do this thing in C# rather than PHP, so that we can use the built-in data handling functions to bind to the database, rather than trying to muck with a custom PHP data abstraction layer. I think the savings we’ll see in being able to use built-in form field object, data binding, and native validation exceptions will be well worth abandoning the work that was initially done on the PHP form, much of which would need to be redone at this point anyway.
Athletics Rosters for the CMS
Progress on this has been going faster than I initially thought it would. I’ve completed the code to add in both normal and captain’s profile text to the roster XML. This profile text will be formatted HTML in a CDATA block being generated using the RadEditor control. I had to work with Brett to get the binaries for this in the right folder on the server and we haven’t used the regular RadEditor yet, just the one that binds to CMS placeholders. Because the roster is one big placeholder, we need to use the basic RadEditor so that we can grab the HTML on postback and insert that into an XML element in the big roster placeholder.
I’ve also completed a couple custom data placeholders, including a checkbox to denote whether the student is a captain or not. The checkbox was really tough to do because ASP.NET will return a non-boolean null value from an empty XML field of type “boolean”, which can’t be converted to boolean in the front-end page. This issue was difficult to resolve because all the online examples are of binding to a database backend, rather than XML, and use SQL statements to fetch the data, rather than XPATH or other XML data lookup functions. I finally resolved it by declaring a default value for the field and manually setting the returned data type in the code behind.
I also changed the user interface in a way that I think will make it easier to use. Initially we wanted to have a textbox in which Brad would type the name of an image, then click a button and the CMS would see if the image was in the Resource Gallery. I was having trouble getting an event handler on a button inside a data grid working, so I changed this to just be a drop down box of the elements of the current resource gallery, which is easier for Brad to use anyway. I just need to add some code to handle the event where he returns to edit a record where the image has moved to a new Resource Gallery.
The bulk of the remaining work on this project is creating a rendering script for the captains channels that honors two potential data sources: captains postings from legacy sites and rosters from new sports year channels. With another solid week of programming I could probably have the whole thing done. Of course, there’s no such thing as a solid week of programming :(
Spam Filtering for Form Email
I mentioned off hand to Brett that we’d had a couple users who were getting spammed by email from a web form submission. He told me that the emails from web forms don’t go through the spam filter because they are treated as coming from “on campus”. He suggested that we send emails to shark.middlebury.edu rather than the default smtp address, to force them through the spam filter.
I made this change on plasma and tested it out. It works better than we thought it would because now email addresses are checked for validity when the form is submitted to the server. A non-valid email address will throw a PHP exception, which I can catch and handle. Now we can assure our customers that any emails addresses entered are real, plus give them spam protection. This will also answer a lot of “why didn’t I get a confirmation email?” questions from people who enter their phone number in the email box. Yes, that has happened.
PHP 6 and the Future of PHP
I’ve spent a bit of time this week reading through the PHP Internals Mailing List, which is the one where the core developers for PHP decide on the direction and new features that are going to be available in future releases. There have been two rather large discussions about PHP recently.
First, one of the lead developers randomly decided to create an extension for PHP 6 which will enable “namespaces”. You’ll be able to declare a namespace at the top of any PHP file and then any classes within the file will be considered as part of that namespace. This means that you can have two Exception classes loaded globally if they are logically referenced as part of two different namespaces. The advantages there are obvious to anyone who’s used a language with real namespaces or even something like Python’s packages. It’s looking like this extension will be part of PHP 6’s core, which will be a large functionality improvement for PHP, a language who’s core function library consists of hundreds of functions, all declared globally. Maybe over time these will be moved into namespaces.
And that’s sort of where the second discussion begins. The PHP team would like to retire support of the ereg_* function library into the PECL extension repository, supporting only preg_* regular expression functions in the PHP core from here on. This, of course, triggered a big discussion about what the development team for PHP would continue to support post-PHP 4.
One of the big issues is whether PHP 6 will have an on/off switch for unicode support in the php.ini file. With it, developers will need to write at least two versions of their scripts: one for unicode and one for non-unicode since the string functions in each will work differently. They may need to develop a PHP 5 version as well if they want to continue support for PHP 5. It was mentioned that this support structure is totally unreasonable for large scripts that are expected to work in multiple environments, many times without the users being able to control what is set in php.ini. It remains to be seen if the unicode on/off switch will remain in PHP 6 and what the resolution of these issues means for PHP moving forward.
Abroad View
Looking forward, it is likely that the focus of most of my work this week will be on the Abroad View site design implementation. We’re going to implement this in straight-up XHTML first so that we have templates that can be used on multiple platforms if we’re not able to get the SharePoint site fully operational by the time needed.
Chris has complted work on a unified Photoshop file for the Abroad View design that cleans up a lot of what the vendor left for us. I’ll be using this file and the images that he sliced out of it to create XHTML versions of the three core site templates: front page, aggregation site, and content site. I expect to spend most of Monday and Tuesday working exclusively on this, with deliverables to present at a meeting with the Abroad View folks Wednesday morning.