First of all, you may notice that there is actually a link for the “Links” item in the nav. Over the past few days, I’ve been designing, coding, and adding the links themselves for this new links system. The building process was pretty similar to all the systems I’ve done so far, especially the Photo Album. I design the page in HTML first, so I can preview how tables and such will look and debug browser compatibility locally. Then I take this HTML page and convert it to server-side form, quantifying item HTML blocks with PHP loops and adding the necessary SQL queries. Somewhere in there, I create the database tables and start adding in records. This is pretty much how every system was built.
The links system is seemingly the most simple system I’ve built so far, but it’s actually a bit more complex. For one, the category (directory) hierarchy is not linked through paths like the Photo Album, but is linked by item IDs and parent category IDs (a tree). This makes sense because the category hierarchy is logical here, instead of being based on physical paths with the Photo Album. The advantage of this method is that items (links and categories alike) are not dependent on a whole chain of parent categories but merely the parent ID. This makes moving items, renaming items, and the MySQL queries easier. The disadvantage being that mapping the category paths is a recursive nightmare.
Another complex part of the links system is the feature that checks link status–whether or not the URL of the link is working. I’ve set it up so that every Friday morning (or when I run it manually), a script will request every link URL in the database. It then takes the HTTP response code from the requests and puts them into the database (this will appear as a popup tip for the link status), decrypting them into a brief OK, MOVED, or BROKEN status that appears for each link on the page. This seems to be working quite bitchin so far, except that FilePlanet always returns 403 Forbidden. I suspect that they filter out non-supported browsers through their default index this way.
Except for any bug-fixes that may pop up, the new links system is done. I’d recommend you comb through the more than fifty links already there; you may find something useful.
I put some more work into my alarm program before getting involved with the links business. Mainly, I’ve been working on improving the stability of the sound system. Luckily, FMOD handles all of the low-level loading, decoding, and outputting stuff for me, but I still have to implement when, what, and how it does its job. My original implementation of FMOD would crash whenever you tried to play two sounds at once. Because I didn’t want FMOD to hold onto some sound resources when alarms aren’t being played, it didn’t initialize until an alarm went off. Thus if two alarms happen to overlap, the second will indeed try to reinitialize the system, crashing it in the process.
I solved this problem by making a simple sound system stack. When the first sound is pushed onto the stack, the system initializes. When the last sound is popped, it closes. This fixes the problem with multiple sounds playing, but now I’m working on a problem when sounds end. I’ve traced this back to the fact that each sound alarm gets its own thread. My next big challenge will be bringing the different alarm threads together into one big sound system thread (with the stack). Easier said than done, but I will prevail!
I was also going to talk about my current gaming trends in this post, but I’ll save that for another time. In the meantime, here’s a rare picture of Kaylen and I out in the sun. Oh noes!