One of the main issues I came across when developing this site, is the integration of all items. Especially when ditching my homebrew framework in favour of several open-source packages, it became difficult to get streamlined yet easily maintainable user-interface. Until now I tackled this problem by using WordPress's framework as main rendering engine all over my site, as I described previously. But sadly this approach had many downsides...
In order to use this engine, I had to get the complete WordPress engine running, which involves fetching data out of the database. This caused an awful lot of overhead, which if combined with my not-so-fast server, made even the most simple pages take over 100ms to render.
Another issue appeared when applying minor changes to the layout. I'd have to go through all template files to apply the same minor change over and over again, a great opportunity for minor human errors to appear.
Clearly the infrastructure had to change... again :) It seemed to me that in order to tackle this problem as definitely as possible, using an external rendering framework would be the way to go. I'd just have to choose a sufficiently complete yet lightweight engine, and rewrite all templates once so they would use that engine correctly. When I'd want to change the layout later on, I would (theoretically) just have to change the HTML-generating files of the render engine, and not have to rewrite each application's template file.
So I went looking for a good template engine. As it's the most used web-scripting language, I focussed on PHP template engines. Ultimately I choose to use QuickSkin above it's more feature-rich counterpart Smarty, a choice I might regret quite fast though.
Having installed and configured QuickSkin, I started porting my current WordPress theme (LoseMyMind) to the QuickSkin framework. This involved splitting the existing codebase into several chunks. During the process I started several rewrites, and I ended up with a widget-based framework. I still have to work out the details (e.g. rewriting and adjusting the entire thing several times), but at the moment every page contains several static widgets (header, menu, sidebar, footer) which are always present and just need to be filled in with data, and other dynamic content widgets (text, post, ...) which are created as the generating page requests it.
Once the framework was more or less completed, I started porting static pages from the WordPress framework to the QuickSkin framework. This caused all code to look a lot cleaner, and eventually those pages rendered a lot faster too (3 to 4 times), a programmers dream :) The resulting code, here showing the main page, ended up as follows:
// Create a blank page
include("/var/www/private/quickskin/setup.php");
$qs_page = quickskin_page
("blank");
// Configure the page
$qs_page->assign('title', 'Home');
// Create a text widget
$qs_text = quickskin_widget
('text');
$qs_text->assign('title', 'Welcome' );
$qs_text->assign('contents', '
<p>Hi, and welcome at my personal site!<br/>
Enjoy your stay, and be sure to check out my all-new <a href="/blog">blog</a>.</p>
<p>maleadt</p>
');
// Add widget to page
$qs_page->append('contents', $qs_text->result());
// Output the page
$tidy = tidy_parse_string
($qs_page->result());
tidy_clean_repair
($tidy);
echo $tidy; Neat and fast code, I request nothing more :) Even more, it provided an easy way to post-process the generated output, as shown in this code fragment. By having the output processed by a properly configured libtidy, the ultimate result is XHTML valid as well as human readable (check the source of this page, it is properly intended thus easily debug-able).
Creating a QuickSkin interfacing WordPress theme proved to be a tad harder, as many of WordPress' functions print output instead of returning it, but I eventually sorted it all out, despite having had to remove some features.
Next up is writing a theme for my Wiki, but a first attempt horribly failed due to the complexity of the themes (many actions have to be themed, varying from viewing ,editing, to annotating and diff'ing) as well as the lack of low-level functions (or I'd have to hack into lower layers of the engine, which I don't want as it breaks upgradability). I'm sure I'll sort it out though, one way or another :)
