Inklog is still chugging along. It currently does everything it needs to do except the fundamental requirement for a blog: listing the items in reverse chronological order. Of course, at this point it’s just a framework, so, even after that functionality is built, it needs a little more before it will stand on its own.
It currently has lots of neat features. It allows the user to leverage his/her existing knowledge of the file-system in order to setup, catalog and configure an entire site. The framework can handle documents of any type (provided a small plug-in is written to handle it). It can then convert that input type to whatever output type is requested by the visitor (provided a template exists for that output type). It knows when the user is requesting a list of items (like the front page’s list of recent items) or a single item. In all cases it follows the leaf all the way down to the roots of the directory tree to determine configuration values and template structure.
The file type of the documents in the file system are determined by their extensions. Additionally, the extension of the file requested by the visitor determines the output type. This means that if a file named “test.txt” exists, and a user requests “test.rss”, test.txt (with an input type of txt) is converted to an output type of rss, and sent to the browser. Along the same lines, if a file named “junk.rss” exists, and a user requests “junk.html”, junk.rss (with an input type of rss) is converted to an output type of html and sent to the browser.
Categories are the same as directories. So, by placing a file in a directory named “Computers” you have added a document (blog entry, whatever) to the “Computers” category. Multiple categories are implemented by using symbolic links, or, in the case that the OS doesn’t support them, a special symlink input type.
Every aspect of the framework allows plug-ins. This means that, if you are a PHP programmer, extending the system is VERY easy. Additionally, there is no complicated API to learn. Instead there are few simple rules to follow. Breaking the rules won’t break the system, it just may not function as you intended.
Every aspect of the output is also configurable simply by editing various template files. One can easily change the layout for an entire branch of the document tree by editing one small file. Knowledge of the output format desired (HTML, RSS, etc) is required, however, defaults will be provided. This means that, if you don’t know what a proper RSS document looks like, then you can just use the templates provided. However, if, for some reason, you want to edit them, you can do so.
Output types also allow varieties. This means that the document “junk.rss” can be accessed as “junk.html” or, with one of the html output types varieties, such as “junk.comments.html”.
Plug-ins have full access to the template system as well as to the configuration system. This means that, plug-ins do NOT have to be configured by editing source code. A simple configuration file (in windows INI format) can be edited to provide any configuration that is needed. And, again, since everything is determined by following the leaf all the way to the roots, one configuration file in the root of the document structure will configure ALL of the branches.
There are three types of plug-ins allowed. The first type is a template plug-in. These are to be used in the output template files to provide shortcuts and advanced functionality. Powered by Smarty, any valid Smarty plug-in can be used. The second type is a module. Modules provided extended functionality such as a photo gallery, comments, trackbacks, and the like. The are implemented by authoring a PHP class, however, no API needs to be utilized. Finally, there are conversion plug-ins. These are called upon when one document format needs to be converted to another. In order to make things simple, all documents, before being displayed, will be converted into a struct containing the metadata for that item. Then, a output template is called to determine how the metadata should be displayed. It is based on the output type selected by the user.
Explaining the system makes it seem fairly complicated. However, in practice, it isn’t. Once your templates are in place, and your configuration parameters are set properly, using the system is as easy as creating a file in a directory.
A web-based administration interface is in the planning phases for those who don’t like using the file system. It, of course, will be fully templatable and will use the existing plug-in system for all of its interactions. It will allow remote installation of plug-ins from a repository, the editing of templates and configuration files, as well as the uploading of documents to be served.
All of the URIs in the system are configurable by the user. Installing a plug-in is as simple as adding a file to a directory. Using the plug-in is as simple as editing your template files.
All this being said, it isn’t quite usable yet. Because of the nature of the system, documentation will be required. Additionally, a good set of defaults needs to be in place to make it easy for users to get up and running.