Calendar 1.2

The next major revision of Calendar is done. Calendar 1.2 simplifies Calendar 1.1, reducing the CSS requirements and overall shortening the code by over 100 lines. It also abstracts the process of generating HTML, which used to be done in the Calendar object itself but now relies on templates with loops—a feature of Parser 1.2.

Currently Calendar 1.2 needs three templates. This is due to the inability to nest loops. This does give pretty specific control over how each section will look, though. The only lost functionality is the ability to use completely different CSS for "big days," used to display seven days or less, and "small days," used for two-week and month displays. Practically, the only difference was a height factor, which could easily be changed on a page-by-page basis, or left to float, with a min-height attribute.

With these major revisions of Parser and Calendar I am now going back to work on User 2.0. If anyone has advice on the best way to do session-based user login, let me know. Version 1.0 serialized the itself and stored the data in the session. Any new User object would check for the session data, and, if found, copy the data into itself. I can't decide if I want to do something like this again, or store the whole object in the session.

Parser 1.2

On the way to Calendar 1.2, which will use Parser to simplify the process of looping through days and make it, yet again, easier to update, I realized my templates were going to be bloody long and fairly ... static, so I had to update to Parser 1.2.

Parser 1.2 has yet another new feature: foreach loops. This allows you to--OK, here it gets complicated--define as a variable an array, call it $Loop, of associative arrays, say $Data, with tag => value data. Each $Data has the same array keys (theoretically) and different array values (theoretically). Then you put in the template something like:

{foreach:loop}
{name1} likes {name2}<br />
{endforeach:}

This would print, provided the tags name1 and name2 were defined in each member of the variable "loop," one row of who-likes-who for each member of "loop." The structure is something like...

$Loop = Array (
0 => Array (
  "name1" => "Jessica",
  "name2" => "Mark"
),
1 => Array (
  "name1" => "Stewart",
  "name2" => "Leslie"
),
);
$parser->addVariable("loop", $Loop);

And this would print something like, using that template above:

Jessica likes Mark<br />
Stewart likes Leslie<br />

The potential here is obvious. It's a little tricky, yes, and not something one would want to do by hand, but it's not too hard to do it automatically, having another loop add arrays to the $Loop array before adding it as a variable. This is exactly what Calendar 1.2 will be doing.

All I wanted to do was streamline Calendar, and I ended up with a whole new control structure in Parser. Imagine that.

Exterminating

There's nothing like trouble-shooting and bug-killing.

Some minor fixes:

1) The doLogin script had been modified to use a static redirect some time ago, and I never noticed. Basically, instead of users redirecting to a login page and then back to the page they wanted, everyone went to the homepage after they logged in. Easy to fix.

2) Through my complete oversight, the system allowed blank usernames. Well, since a blank string will evaluate as false, this was also a pretty easy fix. Now you can neither log in nor register if your username evaluates as false.

FrameWorks 2.0

If nothing else, I'm learning a lot about practical programming through this project.

The original backbone, FrameWorks 1.0CI, had more bugs than your average Microsoft release, and was about as useful as anything before Service Pack 2. It couldn't do much of anything, except handle user authentication and basic data access. The "CI" part of the version also meant it had been rewritten for PHP4, and lost a lot of its performance.

The first part of the new version, FrameWorks 2.0, was the Calendar object, an abstraction of basic calendar functions, which I talked about in the last post. Calendar is currently in version 1.1.2, but I'm hard at work on version 1.2.

The Calendar object caused me to build a Math object, which is nothing but a bunch of static functions (I love PHP5) to do basic math that PHP doesn't have built in, like a true modulo function. Math basically augments versions every time I find a new function it needs.

I also created my own exception class, called Error. Currently in version 1.0.1, Error simply cleans up the messages created by the built in Exception class.

The next big project was a template parser, called, simply, Parser. Parser is like a slimmed down version of Smarty. It's missing some of the big features, mostly because it works much differently. Smarty, for instance, compiles templates into workable PHP code. It then caches these compiled files. It doesn't have true page-caching. Parser, on the other hand, doesn't compile templates, so it can't cache them, so, summarily, it has no caching system (yet). Since all the pages are dynamic, I'm not too worried about this, either.

Parser 0.1-1.0 involved a built-in Menu system, which would create automatic variables known to fill in a menu and submenu. Parser 1.1 ditched this (retrospectively dumb) idea for two much more powerful implementations: template inclusion and basic boolean logic. This pretty much eliminated the need for a difficult-to-implement menu system anyway. Now it's much easier to just create a "menu.htm" template with various if/then statements to decide which link to highlight or whatever.

Parser also uses an internal object called Translator. This is my first real stab at multiple language support. Language files just have an associative array with the text label and translation. This will let the new version of the OTS support users native languages. And through the Translator, the Parser can interact with the Calendar to change the language and date formats there, too.

Also new is an RSSFeed object, which will be able to automatically generate RSS feeds (either static files, like through cron or publishing script, or dynamic through another script). The idea for the OTS is that users will be able to subscribe to a feed with their next 10 appointments or something.

Finally, major updates are planned for both the DB and User classes, which should both be in a functional 2.0 by the end of the week.

Background Info

As this is supposed to be a partial record of the development of the OTS, I feel some background is in order.

The system runs in PHP5.1 (previously 4.3) with a MySQL 3.21 backend on Redhat Linux on an IBM Blade Server. The update to PHP5 has allowed me to begin work on a much more advanced backbone which I'm calling OTS2 for now.

Originally, the OTS ran on an object-oriented backbone, called FrameWorks, I designed as an abstraction of several important functions I'd been using, such as user authentication and database access. But as the needs of the project developed, it became relatively obvious how limited this system was. It was also a huge performance problem, as it relied on an object-inheritance tree. (There was a root object called "Object" which did nothing but figure out the name of the class and generate a microtime stamp.)

Currently, most of the system still runs on FrameWorks 1.0CI, the original implementation of FrameWorks, adapted for the Confucius Institute (basically downgraded to run in PHP4). However, as I update the functionality of the site, I am slowly transitioning to FrameWorks 2.0beta, a strictly PHP5 update of the previous version. Features of PHP5 that are heavily incorporated in FrameWorks 2 are more advanced error handling via PHP's new Exception structure--user-friendly error messages instead of simple "die();" statements--and the new OOP structures, such as static methods and variables and scope resolution.

The first part to be rewritten as part of FrameWorks 2 was the Calendar system. Obviously, OTS relies on a lot of calendar functions to schedule appointments. FrameWorks 1 didn't even have a Calendar object, so OTS had several pages creating their own, simple "calendars." This took a lot of code, and changing the calendars involved changing the code in all of them. They were also formatted with tables and just generally unpleasant. So I created a new OO system in which a Calendar object stores all sorts of things, including user and server timezone offsets--important when half the users are in China and the other half are in the US--and deals in "Events," which are ordered based on their beginning timestamp. The Calendar can then output a CSS-formatted calendar (all DIVs instead of tables) which can show a day, a week, a month, a work-week, or the next 4 days. Incorporating this reduced some of the code by as much as 80% and unified the system so that changes are now made to one object instead of three or four pages.

The OTS is built, too heavily, on AJAX. This has caused me nothing but headaches since I made the decision. When I started the system, I had just discovered AJAX and how to make it work... I hadn't yet discovered when to make it work. Certain parts of the site benefit from the AJAX framework--the "announcements" system, for instance, which can count down to your next appointment--but the rest suffers. A lot. AJAX is a great methodology for things that actually need to update regularly without page reloads, but it's far too rigid for real page-to-page navigation. Either you end up with hundreds of individual JavaScript functions (like I have) or you simply can't do certain things (also, like I can't), like easily submitting forms. The number of cheap hacks and "workarounds" I've done has made maintenance on the system virtually impossible.

Finally, the real meat of the OTS is a Flash Communications Server. Honestly, I have almost nothing to do with this. We already had the necessary SWF files and just plugged it in. It allows full-duplex audio conferencing along with both English and Simplified Chinese text chat. In these "rooms," tutors and students get together and the actual learning takes place. Lately the only work I've done on this is try to fix the way sessions end and take users to rating pages (stupid AJAX).

That's basically where we stand now. I'll post some more info about the changes I'm working on shortly.

Technical Blog

As the lead developer (only developer would be more accurate) of the Confucius Institute at Michigan State University's Online Tutoring System, I've decided to keep two blogs related to the project. The first is meant for end-users, and is just a review of how features are changing. This blog, however, will be a more in-depth, technically oriented review of changes, problems, and solutions.

I'm providing this for those who are interested in the technical side of things, for any developers--veterans or newbies--who want to comment/ask questions, and also as a record of the development of the OTS.

Enjoy, I have a few background posts to fill in right away.