Index: openacs-4/packages/acs-core-docs/www/apm-design.html =================================================================== RCS file: /usr/local/cvsroot/openacs-4/packages/acs-core-docs/www/apm-design.html,v diff -u -r1.40.2.1 -r1.40.2.2 --- openacs-4/packages/acs-core-docs/www/apm-design.html 9 Jun 2016 08:44:49 -0000 1.40.2.1 +++ openacs-4/packages/acs-core-docs/www/apm-design.html 23 Jun 2016 08:32:45 -0000 1.40.2.2 @@ -26,22 +26,22 @@ Content Repository, the OpenACS Templating System, and the OpenACS Kernel, which includes APM.
An installation of the OpenACS includes the OpenACS Kernel, some services that -extend the kernel's functionality, and some applications intended for +extend the kernel's functionality, and some applications intended for end-users. Packages function as individual pieces of subsites. A subsite can contain multiple application and service instances that provide the end-user with capabilities and content customized to the particular subsite.
This architecture supports the growth of collaborative commerce. For example, Jane User starts a forum focusing on the merits of View Cameras by creating an instance of the Forum application for her personal subsite on an -OpenACS Installation. Jack User discovers Jane's forum and includes a link to -it in his subsite. As interest in Jane's forum grows, she creates a +OpenACS Installation. Jack User discovers Jane's forum and includes a link to +it in his subsite. As interest in Jane's forum grows, she creates a subsite specializing in providing information about View cameras. This subsite now includes several package instances beyond Forum; it could potentially include its own Ecommerce capabilities (ala Yahoo! Shopping). This could include a knowledge management application that allows users to spread expertise about view cameras and a portal application that links to reliable camera models and resellers. Any subsite enabled package that is added to the OpenACS installation through APM is another potential package instance that can -become part of Jane's View Camera subsite.
The APM provides an architecture for packaging software, making instances +become part of Jane's View Camera subsite.
The APM provides an architecture for packaging software, making instances of that software available to subsites, specifying configuration parameters for each instance, and managing the creation and release of new packages.
Prior to ACS 3.3, all packages were lumped together into one monolithic @@ -61,12 +61,12 @@ model should not affect dependent packages. Rather, the package interface should provide a level of abstraction above the data model (as well as the rest of the package implementation). Then, users of the package can -take advantage of implementation improvements that don't affect the +take advantage of implementation improvements that don't affect the interface (e.g., faster performance from intelligent denormalization of the data model), without having to worry that code outside the package will now break.
A typical ACS-backed site only uses a few of the modules included in the distribution, yet there was no well-understood way to pick only what you -needed when installing the ACS, or even to uninstall what you didn't +needed when installing the ACS, or even to uninstall what you didn't need, post-installation. Unwanted code had to be removed manually. @@ -123,7 +123,7 @@ subsites across the system, and be available for distribution to other OpenACS installations without doing a monolithic upgrade or reinstall.
The APM is composed of systems for accomplishing a set of package-related tasks. Each of these tasks comprise a feature area that has an API, data -model, and a UI:
Authoring a Package
Maintaining Multiple Versions of a Package
Creating Instances of the Package
Specifying Configuration Parameters for each Instance
Authoring a Package
Full instructions on how to prepare an OpenACS package are available in Packages. The API here can be invoked manually by a package's data model +model, and a UI:
Authoring a Package
Maintaining Multiple Versions of a Package
Creating Instances of the Package
Specifying Configuration Parameters for each Instance
Authoring a Package
Full instructions on how to prepare an OpenACS package are available in Packages. The API here can be invoked manually by a package's data model creation script, but need not to be used. This API is part of the APM PL/SQL package.
@@ -232,7 +232,7 @@ ) return apm_package_versions.version_id%TYPE;
Versions can be enabled or disabled. Enabling a version instructs APM to -source the package's libraries on startup and to make the package +source the package's libraries on startup and to make the package available to the OpenACS.
procedure enable ( @@ -467,7 +467,7 @@ table where each package is registered. When a new application or service is installed on an OpenACS instance, a corresponding row in this table is inserted with information about the type of package, e.g. if the forum package is installed on your OpenACS server, a row -inapm_package_types
will be created, noting that it's an +inapm_package_types
will be created, noting that it's an application package type.The
apm_packages
table is used to contain information about the instances of packages currently created in the system. Thepackage_key
column references theapm_package_types