| Prev | Chapter�15.�Kernel Documentation | Next |
|---|
*Note* This document has not gone through the any of the required QA process yet. It is being tagged as stable due to high -demand.
An OpenACS 4 subsite is a managed suite of applications that work together for +demand.
An OpenACS 4 subsite is a managed suite of applications that work together for a particular user community. This definition covers a very broad range of requirements: from a Geocities style homepage where a user can install whatever available application he wants (e.g. a single user could have their @@ -16,7 +16,7 @@ the Request Processor. Since the design and implementation directly associated with subsites is actually minimal, a discussion of subsites design is, in fact, a discussion of how core OpenACS 4 components implicitly support -subsites as a whole.
The subsites problem actually has several quite diverse origins. It was +subsites as a whole.
The subsites problem actually has several quite diverse origins. It was originally recognized as a toolkit feature in the form of "scoping". The basic concept behind scoping was to allow one scoped OpenACS installation to behave as multiple unscoped OpenACS installations so that one @@ -31,14 +31,14 @@ consistent theme among all of them is the concept that various areas of the web site have their own private version of a module. Because this theme is so dominant, this is the primary problem that the OpenACS4 implementation of -subsites addresses.
The current implementation of package instances and subsites allows +subsites addresses.
The current implementation of package instances and subsites allows extremely flexible URL configurations. This has the benefit of allowing multiple instances of the same package to be installed in one subsite, but can potentially complicate the process of integrating packages with each other since it is likely people will want packages that live at non standard URLs to operate together. This requirement would cause some packages to have more configuration options than normal since hard-coding the URLs would not -be feasible anymore.
This section will cover all the APIs relevant to subsites, and so will consist of portions of the APIs of several systems.
Packages
The following package is provided for instantiation of packages. The apm_package.new function can be used to create a package of any type known to the system. The apm_package_types table can be queried for a list of @@ -189,15 +189,15 @@ [ad_conn package_url] -
The subsites implementation doesn't really have it's own data model, although it depends heavily on the site-nodes data model, and the APM -data model.
The primary elements of the subsite user interface consist of the subsite +data model.
The primary elements of the subsite user interface consist of the subsite admin pages. These pages are divided up into two areas: Group administration, and the site map. The group administration pages allow a subsite administrator to create and modify groups. The site map pages allow a subsite administrator to install, remove, configure, and control access to packages. The site map interface is the primary point of entry for most of the things a -subsite administrator would want to do.
The current subsites implementation addresses the most basic functionality +subsite administrator would want to do.
The current subsites implementation addresses the most basic functionality required for subsites. It is likely that as developers begin to use the subsites system for more sophisticated projects, it will become necessary to develop tools to help build tightly integrated packages. The general area @@ -208,4 +208,4 @@ a particular configuration of site nodes/packages. As we build more fundamental applications that can be applied in more general areas, this feature will become more and more in demand since more problems will be -solvable by configuration instead of coding.