Some users have wanted a simpler way to integrate SyntaxHighlighter into their sites. Last year, David Chambers wrote a script that uses the Prototype library to load the required CSS and brush files. He ran into a troubling quirk in SyntaxHighlighter: It needs any required brush files to be loaded before it starts highlighting. I responded by updating the OOWB fork of SyntaxHighlighter, so that brushes could be loaded asynchronously. But that’s as far as I’d gone towards automated loading, until now.
I recently looked into adding automated loading to SyntaxHighlighter itself, coming up with not one, but two automated solutions. I should really say one and a half, as one is still in the alpha stage and will likely stay there.
To use this new method, the web page invokes
SyntaxHighlighter.boot instead of
boot is used as the entry point, SyntaxHighlighter determines which brushes are required by the web page, and issues HTTP requests for each brush file (as well as the appropriate CSS.) These requests use the age-old method of adding a
tag for each brush, and a
tag for each CSS file.
SyntaxHighlighter.boot, a web page only needs to add a couple of scripts, usually at the end of the
. No CSS link elements are required.
That’s it. Every page on your site can use the same set-up, regardless of which brush files it needs. (For another example, look at the HTML source for this page.)
When an HTML page includes external scripts—that is,
src attributes, the browser loads the script files synchronously, as it encounters them in the HTML. When the scripts are loaded dynamically, the browser can load them asynchronously; several scripts may then be loading simultaneously. This can be particularly helpful for pages that use multiple brushes. Here’s a Firebug sequence diagram of a web page with five brushes, loading in SyntaxHighlighter’s traditional way:
Here’s the same page, modified to use the
boot method. Notice that, unlike in the first picture, the
.js files are loaded in parallel:
Of course, this isn’t an entirely new discovery, but it came as a pleasant surprise nonetheless.
In addition to SyntaxHighlighter itself, I also modified Viper007Bond’s SyntaxHighlighter Evolved plugin for WordPress to use the new
boot method. This simplified the code quite a bit, though it may have introduced bugs.
SyntaxHighlighter and SyntaxHighlighter Evolved are each available on the downloads page. Test before using. Note: If you’ve been using SyntaxHighlighter Evolved, you will probably need to re-set your settings if you install this plugin.
In the traditional SyntaxHighlighter, all brushes must be loaded before
SyntaxHighlighter.all is invoked. In this fork, “>brushes can load at any time after
shCore.js has been loaded. This flexibility was key to the design of the
boot method: If a brush is loaded after
SyntaxHighlighter.boot is invoked,
SyntaxHighlighter looks through the page to see if there’s any input requesting the newly loaded brush.
boot method needs to map each brush name to the script file that implements that brush. I implemented this by modifying the Perl script that builds and stages SyntaxHighlighter. The script now parses the *Brush.js files in the source tree, pulling out the names and aliases supported by each file, and writes them into an array in
shCore.js. The downside of this is that testing via the
boot method requires re-running the script, which builds and stages the files into a new directory, from where I can run tests. Even though the script only takes about a second, it’s crossed the boundary between having no build step in the development cycle, and having any build step in the development cycle.
When You Come To A Fork In The Road, Take It.
I do have some more goals in mind for SyntaxHighlighter. I’ll be writing about them in the not-too-distant future.