Late Start Day!
Wednesday, September 29th, 2004Tomorrow is a late start day, meaning that I can blog without feeling guilty. I might as well skip the part about saying that I’ve been busy; its obvious when I haven’t blogged in two weeks. This one will be shorter because I still don’t have that much time, so I’m going to talk about the plans for the CSHS website rather than about me (my latest entries seem to center more on me lately than anything else, which isn’t good).
We’re moving along quite nicely, in my opinion, though it might not seem like it. The pretty new look that I developed back in March was applied on September 1st and seems to be holding up quite well markup-wise. Normally, I’ll design a theme and find out later that I need to completely redo a part of it to accommodate some new feature, but the CSHS layout and design has only needed minor changes to remain flexible. I took my first stab at creating icons the other day when I made an attachment icon for the news posting system, but other than that the only tweaks to the design have been small (borders, gradients, additions because of dynamic modules).
If you visit the site right now (http://www.cshsweb.com), it’s not that much to look at, beyond the pretty new design. Content-wise, it is still lacking because I’ve been waiting for new content to arrive. Now that I’ve finally got it, I’ve found that the rudimentary backend page organization system that keeps all the pages and tabs on track has some major bugs (try the Counselors link to see what I mean). I could either spend two hours fixing this, or I could just implement my newer system that has been in development for the last three weeks. There are two problems with this solution, however.
First, my newer system (code-named Rancho for the street I live on) requires PHP version 5. It doesn’t work better with version 5, it doesn’t like PHP 5 more, it requires it. In other words, Rancho will not run on PHP 4 or lower. I have PHP 5 installed on my development computers at school and at home, but the school’s web host, who happens to be one of my clients, still uses PHP 4.2. Not only is version 4.2 not PHP 5, it’s an outdated version of the 4.x line (the latest 4.x version is 4.3.9). Put simply, my brand-new system is useless unless the upgrade is done. It’s not that I didn’t know that this situation would arise, it’s just that I had planned for the new system to be put into place much later than now, by which time I hoped that the web host would have upgraded by its own accord. The second problem with using the new system is that it is not even alpha quality, meaning that it is possibly bug-ridden and could crash under major stress because of a lack of testing. Of course, the best way to test it would be in a live situation, so that’s not such a bad thing for me, just a bad thing for visitors.
So all I have to do is get the web host to upgrade to PHP 5, right? It’s not that easy. The school’s host is a reseller for another, larger hosting company that probably puts thousands of websites on a single server. Upgrading PHP on the school’s server could possibly impact the other websites that are virtually hosted on the same server because applications written for PHP 4 (such as this blogging system) are sometimes broken by upgrading to PHP 5. Most programmers have already updated their code for PHP 5 compatibility, but not all. Anyway, there’s a good chance that the larger hosting company will tell the school’s host that the upgrade can’t be done because of the possibility of impacting others on the server. Meaning that we then have to search for a new web host, one that will support PHP 5.
Again, not that hard, right? All we have to do is cancel our current account and sign up with another host. But if you remember, our current webhost is a client of mine, meaning that I would be taking business away from him by moving. That certainly won’t help our relationship. Then again, he might be perfectly fine with it. He said that he’d get a reply from “Big Hosting Company X” by today, so hopefully I’ll know something by tomorrow.
Rancho itself could become a really awesome app. Everything is built around a page framework where each page of content is stored in the database and can call upon plugins to add extra functionality, such as the latest news blurbs or a list of users or site statistics (the possibilities are truly limitless). About 40,000 lines of code is enough to have the following major features implemented already:
- Fully dynamic page management system
- Authentication/profile system is in place but not heavily implemented (yet). Each page is owned by a user or a usergroup (a large collection of users such as Webmasters or Students) who can do whatever they want with the page as well as grant control to another user so that they may make changes too.
- The following plugins: School News and Statistics, which uses flash to generate the prettiest graphs I have ever seen done by a web-based application. (Seriously, they rock.)
- Full page metadata, meaning descriptions of what they contain as well as the times that they were created and modified. This allows for the generation of extra data such as the exact number of years, days, hours, minutes, and seconds since the page was added or modified. This is a nice feature for visitors as well as for admins who need to check to see which pages are oldest and likely in need of updating.
- Dynamic page styling which allows pages to overwrite the global stylesheet in order to make page-specific style changes. Theoretically, a page could have a completely different layout from the rest of the site and remain the same backend-wise as the other pages.
Features that I’ll be implementing soon include:
- Page check timestamps, which allow an administrator searching for outdated pages to mark a page as having been checked on a certain date and time so that other admins don’t check the same page until some time has passed. VERY USEFUL for sites with multiple admins, which CSHS will end up having when I retire from my position in the next two years.
- Complete administration area for the management of the site in several formats: plain HTML, pretty HTML/JavaScript/ActiveX for Internet Explorer users, and prettier XUL for Firefox users. Browser-specific layouts are iffy, but they’re doable. (And I’d like to try, at least.) The nicer admin area formats would provide near-WYSIWYG (what-you-see-is-what-you-get) functionality, meaning that admins won’t have to muddle about with HTML. Firefox has a companion program called Composer which is for creating web pages (though it’s not very good right now), and parts of that codebase could possibly be used for the editing components in the XUL formatted admin area.
- Possibly wiki-like page versioning, which would allow administrators to restore pages to older versions if they make a mistake or if the site is somehow hacked.
As far as I know, there is no other content management system (CMS) that brings together these kinds of features, which is why I’m so excited about it. Most CMSs use a modular approach where you see one page with a selection of modules such as news, forums, downloads, memberlist, etc. My system is the first working one that allows modules to be plugged in anywhere on a page in a truly modular fashion. So yeah. Some of these features may never get implemented, but there’s a good chance that they will if I continue to have time to work on Rancho.
Some things, especially the admin area, will require some serious abstraction to work. The idea is that you would be able to use the same code to generate any of the three interfaces by masking the background work with objects and methods. So if I wrote code like this:
$admin = new AdminPanel();
$admin->setPanelType('xul');
$admin->generatePanel();
the XUL panel would be loaded. If an Internet Explorer needed to use the admin panel (IE doesn’t support XUL), I can just use the same code, the only change being that ‘xul’ would change to ‘ie’. The AdminPanel object is smart enough to run the right code in the generatePanel function depending on what the panel type is set to. Understand? This is called abstraction, a method often used when working with multiple databases.
Pretend that you write a PHP application that stores its data in a MySQL database, the most common database used with PHP. A database query to retrieve your data might look like this:
$conn = mysql_connect('hostname','username','password');
mysql_select_db('databasename',$conn);
$sql = \"SELECT * FROM mytable\";
$result = mysql_query($sql,$conn);
while($row = mysql_fetch_array($result)) {
echo($row['mycolumn']);
}
mysql_close($conn);
This code might look scary, but it’s actually quite simple. In the first line, you are opening a connection to the database using your username and password and storing the connection in something called a variable. Variables in PHP are the same as variables in math: they can mean or represent just about any value. In the second line, you are choosing which database you want to use, using the connection you made. In the third line, you store your SQL query in another variable. The SQL query is somewhat complex at first; just realize that it is grabbing some data from a table in the database (something like grabbing the data from an Excel worksheet). You then perform the query using the mysql_query function, and the result of the query is stored in yet another variable. Finally, you use a looping construct called a while statement to ‘loop’ through the results of the query. This is similar to looking at each row of an Excel document one at a time. Inside the while statement, you can perform operations on the data in that particular row. Because the while statement continues to loop until it has cycled through all the rows in the query result, the code inside the while statement is repeated for each row. In this case, we are simply using the echo function to output the content of the cell ‘mycolumn’ to the browser. Anyone who views a PHP page like this will see all of the cells in a single column of a database table, similar to hiding all columns but one in an Excel sheet. The last step is to close the connection to the database with the mysql_close function. That wasn’t so hard, was it?
You finish coding your application and sell it to a few people. However, one client requests that your application use a PostgreSQL database rather than a MySQL database. In your code, you’ve used MySQL-only functions, meaning that you have to go through your code and change every SQL query to make it PostgreSQL compatible (in larger applications, this could be nearly impossible to do). How could you have avoided this? Abstraction, of course. The above code would look somewhat like this if abstracted:
$db = new Database();
$db->setType('pgsql');
$db->sql_connect('hostname','username','password','dbname');
$sql = \"SELECT * FROM mytable\";
$result = $db->sql_query($sql);
while($row = $db->sql_fetchrow($result)) {
echo($row['mycolumn']);
}
$db->sql_close();
What has changed here? Instead of using PHP’s native database functions, these functions have been masked, or abstracted, by an object stored in the variable ‘db’. Otherwise, everything is the same - the script will output the exact same data to users. However, since you are using generic, abstract functions rather than the native ones, you can change to a different type of database simply by setting a different type with the setType function. The above code will work with PostgreSQL; if I want it to work with MySQL, all I need to do is change ‘pgsql’ to ‘mysql’. It really is that simple. Programmers are inherently lazy, and you have just saved yourself tens of hours (with larger programs) if you use abstract functions rather than native, specific ones.
I did my best to explain this, feel free to email if you have questions. I want to get better at explaining programming concepts so that I can explain things better to the people I work with. (Oh, and I need to get some practice in before I write my book!)
Kreed.
Update
As you can see by the weird fontage in the code snippets and the tiny feature list text, there are some style problems. I’ll fix it tomorrow morning.