Slash's Wiki Pluginby chromatic, coauthor of O'Reilly's Running Weblogs with Slash
The latest stable version of Slash comes with several interesting plugins, and most future Slash development will probably involve creating new plugins. In this article, Slashdot's chromatic introduces the Slash Wiki plugin, which integrates nicely with Slash and has a lot of cool features. chromatic also gives a detailed explanation of how and why the Wiki plugin works, including Wiki theory, and its simple plugin architecture.
The latest stable version of Slash comes with several interesting plugins, including extra blocks (pointers to remote RSS feeds), an internal and external messaging mechanism, and a user journal system. Other projects are also starting to appear, such as lead developer Chris Nandor's Slash::Gallery image gallery.
In theory, any Web application could be reimplemented as a Slash plugin. In practice, it's not terribly difficult to write something useful. The Slash plugin framework provides several nice features:
- A templating
Built around Andy Wardley's superlative Template Toolkit 2, Slash templates can be compiled into the Web server at startup for big performance gains. They are stored in the database and can be edited by users with appropriate clearance through a Web interface or through the filesystem.
User accounts, authentication, and
The base Slash system already provides a means by which users can create and manage their accounts. As authentication is handled by Apache and mod_perl early in the request cycle, user information is available to any plugin. Authorization will be easier and finer-grained in future versions, if the optional access controls become part of the core. (I expect this to be the case by Slash 3.0, and perhaps in 2.4.)
Because Slash is so heavily tied to a database, there are several methods and functions for common database operations. If you're familiar with the common Perl DBI module, you'll be pleased to know that it's supported, though with several abstractions around
DBI::prepare(), you may never need to use a raw statement handle. Also, as support for databases besides MySQL improves, writing portable plugins may be easier. (If you must create new tables, you may have to find someone to port some SQL commands, however.)
- Fairly easy
Though it may surprise anyone who's wrestled with the early versions of Slash, the installation procedure is much improved. (Some might suggest it had no place to go but up.) With a little work on your part, installing a plugin is nearly as easy as installing a pure-Perl module from the CPAN.
There may be more enhancements for the core storytelling Weblog feature, but most future Slash development will probably involve creating new plugins. I wouldn't be surprised to see the message board itself spun off into a plugin. Slash would then become a generic application framework. Of course, as the Slashcode project is sponsored by the owners of Slashdot, the software's primary duty is to run Slashdot. Slashteam's smart and talented enough to make things the rest of us can use, though.
|"The nice thing about a Wiki is its simplicity."|
While the story and comment format is fine for discussions, there's a whole class of collaborative work that can't be done with a standard Slash site. Occasionally, it's useful to have a brainstorming session, where getting ideas down coherently is more important than following a traditional call-and-response question format. Business people call this "synergy," but it really means something here.
Though I can't prove it at the moment, I suspect that's what lead Ward Cunningham to come up with the idea of a Wiki. It's like one of those smart whiteboards, where anyone can write anything and erase anything, but there's still a record of all revisions. The theory goes that putting simple but effective tools in the hands of smart people and staying out of the way can produce great results.
So far, it's effective. The Design Patterns and Extreme Programming folk (and they do overlap somewhat) regularly use Wikis like the Portland Pattern Repository to communicate. The editors and developers of Perlmonks keep track of site issues and create and edit site documentation on special Wiki nodes. The Perl Kwalitee Assurance team maintains a list of untested and undertested core Perl modules.
The nice thing about a Wiki is its simplicity. There are just a few formatting rules, and it's available to anyone who can manage a few HTML forms in a Web browser. They're simple to create and maintain. Perhaps best of all, it's very easy to create and to maintain links between documents. (I like similar things about the Everything Engine, though I'm partial.)
It's very easy to write notes, definitions, or even full documents in places where you have several trusted, geographically diverse people who might use the powerful automatic linking to good effect. Several free software projects have their own Wikis to answer user and developer questions, and these often become fully fledged FAQs. If there were a Slash Wiki plugin, you could even write stories or site guides or your own site FAQ.
|What's your take on future Slash development and new plugins?|
Good news. It
exists! If you have a Slash 2.2 or better site,
installation is very easy. Just unpack the tarball into the
plugins/ directory beneath your Slash site directory, run the
Makefile.PL file, then
make test, and
make install as root, and
install-plugins program. You'll be on
your way to Wiki goodness. Things should just work, if only
because Jesse Hirsh found
several bugs in the beta. Thanks!
This wouldn't be much of an article on Slash, though, if it didn't go into more detail on how and why the plugin works. First, you have to know a little more about how a Wiki works.
The central component of a Wiki is the idea of a page--a single essay or a discussion on a named topic. Anyone can create or edit a page, and all of the pages on a Wiki can potentially be linked together by name. These names follow a Java-esque StudlyCaps format, and anything that looks like a page name will automatically become a link to the page of that name. This encourages extensive linking, and the ease of editing encourages people to fill in the gaps.
There are three basic types of operations that the Slash Wiki performs.
The simples and most common operation is to display a page.
Generally, the user will request something like
CreatingGoodLinks. The plugin searches for a page of
that title, formats it if necessary, and displays it along with
editing controls. If the page has not yet been created, a
default message will display. The user can choose to add
to the page or to follow a link to another page.
Editing pages is also common, though probably less so than viewing them. (The same assumption applies to the number of people who feel compelled to comment on a story versus those who merely read it.) This operation requires updating the database to add the current version of the page, to archive the previous version (for reference or abuse protection), and to display the new version.
The Slash Wiki handles this a little differently, actually storing the rendered version of the page along with the raw, Wiki-formatted version. It's a slight performance improvement. (If a page is edited once for every ten views, and if the raw version is stored to make editing easier, you can trade a little extra storage space to avoid the performance hit of re-rendering things for the nine other views. In retrospect, that would help some of the performance issues of modern Everything Engine releases.)
This is also a place to implement stricter access controls. For a site FAQ, it may be appropriate to restrict writing to users with the Author flag set, or a seclev of over 100. Admittedly, this runs counter to the trustful Wiki spirit, but it may work better for your purposes.