AxKit::App::TABOO is a collection of Perl modules that takes an object oriented approach to creating a publishing system on the top of AxKit, the XML Application Server. The two O's thus stands for Object Oriented, AB for AxKit-Based. I don't know what the T stands for yet, suggestions are welcome! (But recursive acronyms are a bit used up...)
You can get it from your nearest CPAN mirror, or right here. The code is also available from an SVN repository, where it can be checked out with http:// and svn:// (committers can also use svn+ssh://). It's of course free software (under the same terms as Perl itself). The distribution comes with some SQL, which you can use to create a database, include some minimal data that every installation needs, and also some test data you can insert to get started.
There are three main ideas that forms the basis for TABOO:
With TABOO, everything that interacts with AxKit just interacts with the Data objects. That means, if you don't want to store things in the PostgreSQL database my Data objects use, you could always subclass it, rewrite the classes or whatever. You would mostly just have to rewrite the load method. It is also the Data object's job to create XML of its own data.
But it is not just that you can extend TABOO by adding Data objects or subclassing existing objects, after all, the amount of code allready written vastly exceeds TABOO, but it should also be possible to extend existing code by adding the abstraction layer of Data objects.
You can play with the development server! You can log in (as foo or bar with password trustno1) and post stories, edit them, see them on the front page, etc. There is actually quite a lot more functionality in the code than shows here, but I have to take one thing at a time...
The first thing it is, is a Slashdot-like news site with comments... But that's just the start! It partly also does more static articles, the kind of stuff you would want to have indexed and given to a larger audience for a long time to come.
It is an beta right now, and is actually running in production as ski-o.com. It is also approaching ready for deployment at the main site is was developed for.
But to answer your question, a bunch of Data objects with most of their core functionality has been implemented and is present in the current distribution. They provide an abstraction layer that can manage the data for each of the types. They can load data from a data storage, currently a PostgreSQL data base, and they can write their data as XML. Also, there are Plural versions of the data objects, to ease the task of working with several similar objects of the same type.
Secondly, a number of Providers has been written, that's what's using the Data objects. They can can create pages containing an editor-review story and user-submitted comments, and lists thereof, as well as making lists of articles and stories that has been classified in some categories. By simply manipulating the URI in easy-to-understand ways, you can load just the story, view the comments, separately, in a list or as a thread.
Finally, numerous XSP Taglibs have been written that among other things allow you to write XSP pages and have data saved, in the current implementation to the PostgreSQL database. In fact, the XSP has also been worked on, and will allow you to submit, edit and save stories.
There is also some user-management code, including authentication and authorization, to allow adding new users and editing the information of existing users.
I've made some efforts to i18n it, since multi-lingual sites are important to me. I've done it in this implementation by adding a stylesheet at the end of the pipeline, which inserts phrases from a separate XML file. This works well for translating whole sites, but for true multilingual sites, it would be needed to store the e.g. the same story in several different languages in the data store.
Also, I've been working with some code to make a simple webshop so some data objects are allready there for that purpose, but they are not really in a usable state, and since they have fallen behind the rest of the code, they have been removed from the latest distro. It should be rather easy to get them uptodate and merge them back in however.
I'd like to tell a bit more about the ideas behind taking the path that I've taken:
It is a fundamental design choice with TABOO that all data is to be abstracted to objects. I noticed while looking at other people's code, that though it was a lot of interesting code, it would be rather hard to integrate all the interesting parts into a coherent whole. Furthermore, everybody has their own way of storing data, and scattered files or different databases didn't seem right to me.
The intention is to write Data objects for every kind of thing you might want to do. From the start, there will be Slashdot-type stories of varying length, with comments. These are ever-changing in the sense that people can come in an add comments at any time. The other thing we start out with is more static and longer articles.
It is the intention, however, that TABOO should be a framework where one can add a Wiki, a webshop, etc. The AxKit::App::TABOO::User class will then be reused and probably subclassed with e.g. a Customer class (now existing!), but the datasource will be the same. It would also be nice to let Mailman interface with TABOO (or Sympa, which I have become more interested in lately), so people wouldn't need to have more passwords on a single site. Shouldn't be too hard, I think. For the wiki, a Subversion based datasource seems to be a good choice.
Once the Data objects are done, one may use different AxKit systems to interface with those objects, whether it is XSP taglibs, Providers, Plugins or whatever. This creates a greater flexibility. So, it is not just the idea that people should write for TABOO, but that TABOO should use existing ideas by interfacing them with Data objects.
So, hopefully, I can reuse a lot of code from other projects as well, use different backends and frontends for text-entry (which is a major challenge), and for adding logic.
TABOO makes extensive use of Providers. That is mostly because I like the abstraction and direct control of URIs that Providers provide. It makes it easy to create a framework where URIs are sensible and should be easy to maintain for foreseeable future. Also, there is no markup in the code, that's also rather important to make it maintainable.
Metadata is an important aspect that's much overlooked on the web today. Most data I currently store in my data objects might appear to the website user as metadata rather than data. It's not an aspect I have emphasized in the present release, but it is a major issue for the future. I'm really a big fan of RDF.
I'm currently working on code to do image galleries. I think it will build on AxKit::App::Gallery, but more metadata is needed, as well as more flexibility in what to show. Also, authentication is needed.
The current release can also show more static articles. They are not easy to get in, however, and I'll be working on that too shortly, and I plan to use WebDAV for submitting articles.
It is never too early to look ahead of course... In TABOO 2.0, pluginability must be a major focus. Now, you can always rewrite or subclass something you don't like, notably if you want to use a different data source. Currently, it amounts to changing the names of the classes here and there. Not a big deal, but it could create maintenance problems. Solving this is a matter for 2.0, somewhere in space-time.
I can be found at kk@kjernsmo.net and usually hang out on the #axkit IRC channel. Try the mailing list too!
Mainly for Norwegian Skeptics Society. As you can see, those pages look like they were designed in 1996. They were. I've worked on those on my spare time since then, but in 2002, I got some money to develop a new framework. The money didn't last that long, so I had other jobs in between, but now I've just got to make it work. The site I use to show to the folks I'm working for is test.skepsis.no. Nowadays, only content that are relevant should go there. Play with demo.kjernsmo.net instead.