OpenACS Packages

Using the APM application to install, distribute and remove packages specifically used in database applications.
Loading and Installing Packages

The first step in working with an APM package is to load it, which normally means copying it into the filesystem where your OpenACS system resides. If your OpenACS system is under /web/atf/, then all packages go under /web/atf/packages. (For this reason, each package needs a unique name; many OpenACS developers use an Emacs-style package naming convention, in which the package name is preceded by the developer or client name. This helps to avoid conflicts between the foo-attributes and the bar-attributes packages.) Copy the package's entire directory structure into /web/atf/packages, making sure the files and directories are readable (and writable) by the user ID under which AOLserver operates.

An easier and more reliable way to install APMs is to click on the load packages link within the package manager. OpenACS will ask you for the URL of the APM or the name of the directory in which one or more packages reside. OpenACS then will find all of the .apm files located there, unpack and load them into the system.

Once a package has been loaded into the filesystem, you must install its data model and register it with the system. This is done through the web-based package manager, which normally is found under the URL /acs-admin/apm on an OpenACS system. Typically, only the site administrator has access to the package manager.

The main package manager screen shows all of the packages that are loaded in the system and indicates whether each has been installed, superseded by a newer version or is yet to be installed. Using the menu options at the top of the page, you can ask to see different subsets of the packages on the system, including only those that you are personally responsible for developing and managing.

The package manager is the main way in which you create, modify, update and install packages:

  • You can install the data model for a package and register the package with OpenACS. The next time OpenACS restarts, files in the package's tcl subdirectory will be loaded into AOLserver's memory. Your package can be connected to a URL via the OpenACS site map, as we will soon see.

  • You also can use the package manager to create a new OpenACS package. Indeed, the first step in creating a new OpenACS package is to use the package manager to set up a new directory and .info file.

  • You can examine any package currently loaded into the system and retrieve a list of parameters, files or any other information associated with the package.

  • You can modify a package, changing parameters, files and other information associated with the package.

To install a new package, click on the install packages link at the bottom of the page. The package manager will scan the packages directory for any new packages, allowing you to choose which packages should be installed. (When you first install OpenACS, no packages are installed, so this is a very long list.) Each package can depend on one or more other packages. If you try to install a package without its prerequisite dependencies already installed, the package manager will require confirmation before continuing.

The installer lets you decide whether you want to install a package's data model or also enable the package for use on the site. Personally, I always enable any package I install, but I'm sure there are reasons why you might not want to do this. After checking the appropriate boxes, click on the Next button, which installs the data model. Following this, you must restart the AOLserver, because many packages depend on Tcl libraries loaded into AOLserver at startup. Therefore, the packages will not work until the server has been restarted.

Mounting a Package

Once you have restarted AOLserver, go to the package manager and look at the list of enabled packages. All of the packages you loaded should be visible on this list. From here, you can modify the packages, load more packages or begin to turn the loaded packages into an actual web site. This process is known as mounting and is performed using the OpenACS site map. In one of the more confusing parts of OpenACS administration, the site map is not part of the site-wide administration page; rather, it is part of the main site administration page. In other words, you manage packages under /acs-admin/apm, but you manage the site map under /admin/site-map. There are some good reasons for this, but it tends to confuse people more than it helps them.

The site map tells OpenACS how to connect a URL to an application. For example, you might want the OpenACS bboard package to be under the /forum URL or the /bboard URL. In some cases, you actually might want to have it in both places. The site map allows you to do this by clicking the mouse.

To connect a package to a URL for the first time, click on the New subfolder link to the right of the / path. You are asked to name the URL under which the new application should be mounted. To install the bboard package under /forum, you would enter forum (without the leading slash).

If you stop here, you can treat the new subfolder as nothing more than a folder in which new folders and/or static documents are placed. But you also can click the New application link associated with this folder, choosing an installed application package and giving it a human-readable name that will be used in titlebars and headlines. So while you might put the forums under the /bboard URL, you might want to give it the name Discussion forums. This title cannot be changed all that easily, so give this process some thought.

The new application link creates a new package instance and then attaches it to the directory you have created. To make an alias to this application, you can create a new subfolder and then use the mount link. It took me a while to understand that mount lets you connect to existing application instances, while new application creates an entirely new instance. This makes more sense when you consider that unmounting an application (using the unmount link to the right of the pathname) does not delete it but makes it unreachable. To delete an instance of an application completely, you must click on the unmounted application link from the site map, and then click on the delete link next to the unmounted application.

Each instance of an application has its own permissions and its own parameters. I have found parameters to be a particularly useful part of OpenACS, in that they let me create an application once and use it many times, but give each instance its own configuration. Following the appropriate links on the site map, you can view or change the parameters associated with a package instance.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: At the Forge: OpenACS Packages

Anonymous's picture

I am interested in the statement you make I have found parameters to be a particularly useful part of OpenACS, in that they let me create an application once and use it many times, but give each instance its own configuration.
Can you give some detail and examples of the configurable parameters for applications? I am especially interested in how configurable the UI to OACS application pages is. For instance, if I have several instances of bulletin boards configured, can I have them all look different? How would I go about modifying the basic look of an OACS application per instance?
Thanks for your insight:)

Re: At the Forge: OpenACS Packages

ReuvenMLerner's picture

If you're familiar with object-oriented programming, then you can think of package parameters as instance variables: Each instance has the same variables, but different values in each variable.

And just as different objects have different instance variables, different packages have different parameters. The calendar package might have a parameter asking for what language you want to use to display text, and whether weeks start on Sunday or Monday, and what the name of the CSS file is for that package. The bulletin board package might have a parameter to indicate whether it displays messages in threads or chronologically,

Permissions are explicitly not handled by parameters. Permissions are a separate animal, and are set with a different administration page.

In theory, a package can allow its look and feel to be modified using parameters. In reality, most packages only let you change some basic features, and expect the basic look and feel to stay the same. If you want to really change things, then you use CSS at the global level, or the "default master" for the particular site or subsite you're using.

I expect that over time, as people want to customize the user interface more and more, the number of parameters will grow. At the same time, OpenACS is designed to be taken apart and modified, for a variety of reasons.

Does this make sense?


Re: At the Forge: OpenACS Packages

Anonymous's picture

Hi. Yes, thanks.

I also noticed a "skin" package that seems to help customize look and feel of subsites.