As a designer / manager using OpenACS, I find myself wanting more information on the best ways to use OpenACS (rather than develop it). I'd love it if there are people out there managing sites who have tips or hints for working with OpenACS from a administrator's perspective. I agree with Ben Koot's post - I feel like it is an iceberg, and I don't really know how to get the most out of OACS yet. Thanks!

OpenACS has some really powerful features that we would like to expose through this blog. We will try to present features that will be of immediate use to OpenACS developers. However before diving into the deep end, a few basics of OpenACS will be covered within this posting for reference.

OpenACS Packages

OpenACS has transformed from a monolithic code base (3.x and below) to a neater modularised code base in the latest releases (4.x and above). Applications that use the OpenACS framework are now developed in self-contained modules called "packages". All packages are structured using the Model-View-Controller (MVC) pattern.

There are core packages such as the kernel, templating and authentication packages that give you the basis for a web application that supports user, group and application management. You can extend the functionality of a vanilla installation of OpenACS by plugging in already developed packages such as a calendar or wiki through a package installer interface. Or if you can't find a package that provides the functionality you need from OpenACS's extensive package catalog, then you can easily develop your own package.

A package contains an XML based .info file containing meta-data for the package. The core packages use the .info file for dependency checking, as well as for defining properties and specifying call-back commands. The package can also have an SQL directory that contains all SQL files for generating the data model for the application. There is a TCL directory that contains all library procedures for the application. Finally, there is a WWW directory that contains all the presentation logic for the Web application. The structure of the notes package is as follows:

notes

    + notes.info

    + sql

        + oracle

        + postgresql

            * notes-create.sql

            * notes-drop.sql

    + tcl

        * notes-apm-callbacks.tcl

        * notes-init.tcl

        * notes-procs.tcl

    + www

        * index.adp

        * index.tcl

        * index.xql

        * index-postgresql.xql

        * index-oracle.xql

In the SQL directory, the notes-create.sql file is called only once when the application is installed, and is used to create the data model in a database. Currently there is support for both Oracle and PostgreSQL in OpenACS, so depending on which RDBMS you are using, the notes-create.sql will be executed from the SQL sub-directory that corresponds to the RDBMS used.

In the TCL directory, the notes-apm-callbacks.tcl file contains procs that get called when the application is installed/mounted. The notes-init.tcl contains TCL procs that initiate the application when AOLServer starts up. The notes-procs.tcl contains TCL procs that can be used by files in WWW or by other packages.

In the WWW directory, each web page consists for an XQL file, a TCL file and an ADP file. The ADP file contains HTML and templating tags for presentation of data from the data base. The XQL file is an XML based file that contains SQL statements that can be used by the TCL file. SQL statements common to all database systems can be placed in file.xql, whereas RDBMS specific SQL statements can be placed in file-postgresql.xql or file-oracle.xql. The TCL file contains the logic for executing SQL statements and then pushing the returned data to the ADP template file.

That just about covers OpenACS and packages from a high-level overview. In future posts we will start blogging about more useful features in OpenACS.

This is a blog intended for use by OpenACS users. Share your latest tips and hints here!